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INTRODUCTION 

The Simulation Computer System (SCS) is the computer hardware, software, 
and workstations that will support the Payload Training Complex (PTC) at MSFC. The 
PTC will train the Space Station payload scientists, station scientists, and ground 
controllers to operate the wide variety of experiments that will be on-board the 
Freedom Space Station. 

This SCS Analysis Report summarizes the further analysis performed on the 
SCS Study as part of Task 2 - Perform Studies and Parametric Analysis - of the SCS 
Study contract. These analyses were performed to resolve open issues remaining 
after the completion of Task 1 , and the publishing of the SCS Study Issues report. 

The results of these studies provide inputs into SCS Task 3 - Develop and 
Present SCS requirements, and SCS Task 4 - Develop SCS Conceptual Designs. 
The purpose of these studies is to resolve the issues into useable requirements given 
the best available information at the time of the study. 

Figure Analysis 1 gives a list of all the SCS study issues. The issues with a yes 
under the Further Study column are the ones discussed in this report. In some cases, 
one study was performed to address two issues. In these cases, the study number 
reflects the two issues addressed. Figure Analysis 2 shows the outline used to capture 
the results of the further analysis. This outline was developed at the beginning of the 
analysis, and was a great help in organizing the analysis effort. The text in Venice 
Font oti Jifjurc AtvoCysis 2 describes the content of euch section o| the 
outline. 

MSFC is responsible for approving this SCS Analysis Report. TRW will assume 
MSFC approval of this report in the absence of any specific MSFC disapproval within 
30 days of delivery of this report to MSFC. However, it is TRW's current intention to 
include this report as a chapter in the SCS Final Study Report, and thus any 
comments or additions that are relevant and important are solicited. 
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Training Related Issues 


Further 

Study? Issue Num ber & Title 


Yes 

No 

Yes 

Yes 

No 

No 

No 

No 

No 

Yes 

No 

No 

Yes 

No 

Yes 

No 

No 

No 

No 

Yes 


T-1 . 

T-2. 

T-3. 

T-4. 

T-5. 

T-6. 

T-7. 

T-8. 

T-9. 

T-10. 

T-1 1 . 

T-1 2. 

T-1 3. 

T-1 4. 

T-1 5. 

T-16. 

T-17. 

T-1 8. 

T-1 9. 

T-20. 


Scope of Payload Crew Training in PTC 

Scope of Ground Operations Personnel Training in PTC 

Scope of OMS Training in PTC 

Scope of Integrated Core Subsystem Training in PTC 

Fidelity of SS Payload Subsystems Simulations 

Fidelity of SS Experiment Simulations 

Fidelity of SS Experiment to System Interfaces 

Fidelity of SS Internal Data Flows Simulations 

Fidelity of SS Downlink and Uplink 

Fidelity of Element Control Workstation (ECWS) 

Support for Training Multiple Missions Simultaneously 
Support for Integrated Simulations with Other NASA Centers 
Support for Interoperable (Remote Executions) Simulations 
Requirements for SCS Interface with External Facilities 
Requirements for PTC Payload Video Data 

Requirements for Simulation Parameter Update Rate Requirements 
Requirements for High Rate Data Requirements 
Requirements for Virtual Instruments 

Requirements for Simplified Simulator Operations Setup and Control 
Support for Onboard Training 


Associated Development Issues 


Further 

Study? Issue Number & Title 


No 

No 

Yes 

No 

Yes 

Yes 

Yes 

Yes 

No 

Yes 

Yes 

No 

No 

Yes 


A-1 . 
A-2. 
A-3. 
A-4. 
A-5. 

A-6. 
A-7. 
A-8. 
A-9. 
A-10. 
A-1 1 . 
A-1 2. 
A-1 3. 
A-1 4. 


Utilization of SSE Capabilities , . . 

Techniques for Integrating and Maintaining Pi-Provided Simulators 

Techniques for Supporting late changes to simulators 

Allowing Software Transportability between SCS and other centers 
Techniques for Integrating Flight Hardware/Software with SCS 

Simulators . 

Flexibility for Allowing Advanced Technology Insertion 
Implications of Simulation Development Cycle 
Sizing Growth Potential in Capability/Capacity 
Defining Telemetry Data Format and Calibration 
Fidelity of DMS Interface 
Definition of “No single point of failure" 

Requirements for Interfaces with SOAN and SSIS 

Requirements for Configuration Management of Simulation Software 

Definition of GSE-Provided Services 


Figure Analysis 1. List of SCS Study Issues 
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Study Title: Same title of the issue that requires further study. 

Study No. Same number as the issue. Report Version: 

Problem 

Explains the problem, and it’s relevance to SCS. 

Approach 

A brief description of what analysis was done to resolve the problem. 
Analysis Overview 

Summarizes the- analysis so that the details below are understandable. 

Inputs 

Documents or other information used in the analysis. 

Assumptions 

Assumptions made for unknowns or TBDs used in the analysis. 

Analysis 

A description of what was done and how it was done to further analyze 
the problem - used formulas, graphics, consulted documents like 
Architecture Control Documents, Functional Control Documents, other 
Specifications , or consulted people. Results will be shown with the 
analysis for clarity, unless it is clearer to summarize them only at the 

end. 

Results 

A summary of the results. Includes candidate requirements. 

Open Issues/Notes 

Any further issues still unresolved. There should be very few of these. 

Figure Analysis 


2 . Outline Used in Further SCS Study Analysis 
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Study Title: Scope of Payload Crew Training in PTC 

Study No. T-1 Report Version: 6 

Problem 

The load on the PTC simulation computer system was estimated by Study T-1 
(for payload simulations) in early 1989. Since then, efforts have been made to provide 
better definition for the payloads comprising a typical SS complement. This later 
version of study T-1 will make use of more recent information now available to obtain 
the best possible estimate at this time of the required on-line capacity of the SCS due 
to payload simulations. 

Approach 

An analysis of a "typical" payload complement for the US Lab will be performed 
to determine the maximum loading on the SCS at any given time to support payload 
training. 

Analysis will include classifying SS payloads into three levels of simulator 
complexity and then determining CPU sizing requirements using Spacelab payload 
simulators of comparable complexity that have been developed for the Spacelab 
training program at the PCTC as a benchmark. This loading will include requirements 
for attached payloads as well as laboratory module experiments. The loading 
requirements for a single mission will then be factored by the total SS payload 
training, operations evaluations, and development functions that are anticipated to be 
occurring simultaneously during the SS life cycle to determine the total SCS load 
requirements. 

Analysis Overview 

The Multilateral Utilization Study (MUS) was used as the source for a typical 
payload complement in the US Lab for a typical SS mission. The payload complement 
included Materials Science, Life Science, Technology, and Attached payloads. Each 
payload experiment was analyzed based on data flow, video, command control 
requirements, and potential interfaces to SS subsystems such as power and 
environmental control, in order to classify each experiment into one of three categories 
of complexity with respect to their simulation load on the SCS. 

Inputs 

1. Multi-lateral Utilization Study (MUS) Integrated Data Package for Third Quarter 
Studies - 2/24/89. 

2. Operational Timelines for OAST Technology Payloads in the MUS Allocated Set 

3. Interviews with Annette Sledd/ Utilization - ELI 4, Donna Odom/Boeing-Customer 
Utilization, Larry Torre/Boeing-Customer Utilization, and Charles Gartrell/OAST. 
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4. PCTC Experiment Simulator Requirements and Simulator Design Development 
Handbook, JA-711, July 15, 1987. 


Assumptions 

1. A worst case load on the SCS is assumed for payload models which might be 
simulated by either physical hardware or a simulator executing on the PTC bub. 

2. Code size estimates are based on Spacelab experience using istmctured analysis 
and FORTRAN coding. These estimates may be reduced using new CASE tools 
new programming methodologies. 

3 The US Lab payload complement is considered to include all payloads in the US 
Lab US Node plus External Experiments controlled from the US Lab or Node. 

Analysis 


Muiti-iaterai utilization study Payload Compleme nt Bayi£w ami Classificati on 

The payload complement of the mission planning exercise included the 
following experiments: 

Materials Science Experiments 

1. Space Station Freedom Furnace Facility 

2. Modular Containerless Processing Facility 

3. Commercial Protein Crystal Growth Facility 

4. Fluid Physics/Dynamics Facility 

5. Modular Combustion Facility 

6. Commercial Vapor Transport Facility 


7. Commercial Organic/Polymer Facility 

8. Commercial Float Zone Facility 
TpnhnoloQV Experiments 


1 . Quantized Vortex Structures in Superfluid Helium 


2. Solar Array Energy Storage Technology 

3. Surgery Technology Development 
Life Science Experiments 
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1. Habitat Holding System 

2. Multiple Generation Plant Growth 

3. Muscle Loss in Rats 

4. Structural Changes in the Rat's Labyrinth 

5. Space Radiation Effects on Spermatogenesis and Intestinal Villi 

6. Retinal Imaging 

7. Radiation Field Characterization 

8. Cardiac Electrophysiology 

9. Mechanisms of Orthostatic Intolerance 

10. Blood Erythrokinetics 

11. Myocardial Changes in Rodents 


Attached Payloads 

1. Dynamics Stabilization Free-Flyer Robot 

2. Optical Spatial Tracking Spacecraft 

3. Spacecraft Strain and Acoustic Sensors 

4. Low Acceleration Propulsion Technology 

5. Microelectronics Data System Experiment 

6. Advanced Structural Dynamics and Control 

MATERIALS SCIENCE EXPERIMENTS 

Space Station Furnace Facility - The Space Station Furnace Facility (SSFF) is a 
modular facility for materials processing experiments involving metals, glasses, 
ceramics, crystal growth, and electronic/photonic materials. The SSFF is composed of 
5 double racks; one for experiment control and support, and 4 for exchangeable 
furnace modules. Nine different modules are planned! 
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a) Hiqh-Temperature-Gradient Directional Solidification Furnace Module. 
Samples will be processed under very precise temperature and translation 
control conditions. 

b) Low-Temperature-Gradient Directional Solidification Furnace Module. Samples 
processed under very precise temperature and control conditions. 

c) Large Bore Low-Temperature-Gradient Directional Solidification Furnace 
Module. For larger samples. 

d) Vapor Crystal Growth Furnace Module. Thermal and optical sample monitoring. 

e) Isothermal/Rapid Solidification Furnace Module. Complex sample geometries. 

f) Hot Wall Float Zone Module. Quasi-containerless sample processing with optical 

and thermal imaging of the molten zone and solidification interface. 

g) Gradient Freeze Furnace Module. Controlled linear thermal gradient through 
samples. 

h) High Pressure Furnace Module. Directional solidification or casting at high vapor 
pressures. 

i) Thermophysical Property Measurement Furnace. Optical viewing of samples for 

the UV to mid-IR wavelengths, and Laser Holography/Doppler effects. 


Command and telemetry data between the ground and the Furnace Controller 
is estimated at 1 kbps nominal, and 14 kbps peak. Data rates from the experiments 
vary between .5 and 3.0 kbps per experiment. It is assumed that there will be a 

maximum of 5 experiments operating simultaneously. . 

The simulator for the SSFF will have interface requirements to power 
environmental control, and PMMS subsystem simulations. The Facility Controller will 
store experiment timelines, issue commands, perform control and ™ oaiton 
experiments, and acquire and store data. Based on these factors, the Space 
Furnace Facility controller is considered to be complex with respect to the SCS loaa 
In addition, the nine furnace modules are considered to provide an additional SCS 
load of simple complexity each. 

Modular Containerless Processing Facility. - The Modular Containerless Processing 
Facility (MCPF) will accommodate experiments where the sample is not in pnysicai 
contact with the container walls. Samples (liquids, solids, aerosols) will be positioned 
using acoustic, electrostatic, and magnetic fields. Heating is provided by combinations 

of electric furnace, light beam, and laser beams. m 

The facility will include two double bay racks for active experimentation. These 
will accommodate a combination of high and low power experiments. It is anticipated 
thate the facility will utilize an initial set of 4 experiment modules. Only one high power 
experiment may run at one time, but it may run concurrently with lower power 
experiments. The simulator is assumed to be capable of running a maximum of one 
high power, and one low power experiment simultaneously. All microprocessor 
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experiment control is assumed to reside in the Facility, rather than with the individual 

^ Continuous digital data is needed to command and monitor the facility. The data 
interface for housekeeping functions will function at 80 kbps for both uplink and 
downlink. Media standard video, as well as high resolution video will be required for 
setup and monitoring of some experiments. Audio links will be used during periods o 

crew interaction. , 

The MCPF will utilize electric power, water and air cooling, and nitrogen tor 

module purges. Gas venting to the PMMS is also required. . 

The MCPF simulator will have interfaces to power, environmental control, and 
PMMS subsystem simulations. Modeling of housekeeping parameters is considered a 
non-trivial requirement based on the 80 kbps estimated traffic for such parameters. 
Microprocessor control of various heating, cooling, and positioning facilities for the 
experiments is also considered non-trivial. Based on the above factors, this simulator 
is considered to be complex with respect to the SCS load. In addition, each of the four 
experiment modules is considered to impose an additional load on the SCS of stmpe 
complexity each. 


Commercial Protein Crystal Growth Facility. - The Protein Crystal Growth Facility 
(PCGF) is a temperature controlled, microgravity environment for growing protein 
crystals. The facility includes a number of individual protein growth cells, temperature 
control and monitoring system, power conversion system, and a video camera with 
fiber optic interface. It is assumed that a microprocessor controls the temperature, and 
monitors the sample temperatures, power, and other housekeeping parameters. 

Downlink for non-video data is nominally 1 .5 kbps. 

The SCS load for this facility will be limited to interfaces with power and 
environmental control subsystem simulations; simulation of the processor/controller 
functions, and some health and feedback status parameters. Based on these factors, 
this simulator is considered to be of medium complexity with respect to the SCS load. 


Fluid Phvsins/Pvnamics Facility - The Fluid Physics/Dynamics Facility (FP/DF) will 
accommodate experiments to help develop understanding of the fundamental theories 
of fluid behavior, provide improvements in thermophysical property measurement and 
to provide data helpful to fluids-related applications/systems. The facility will consist of 
a Facility rack, and one or more interchangeable Experiment racks. 

The Facility rack will house the user support systems, including a DMS data 
interface capable of communicating 160-250 kbps telemetry downlink, and 20kbps 
uplink. The Facility rack will also enable high resolution, high frame-rate video data 
(2100 mbits/sec bursts). Experiment control will be primarily from the Element Control 
Workstation, with occasional local control at the facility using a portable MPAC. 

The Experiment rack(s) will be interchangeable, each housing a specific 
experiment type. Potential racks could contain dynamic fluid experiments in a Multi- 
Phase Flow Apparatus, or static experiments in a vibration isolated containment 
enclosure. Other potential experiment types involve acoustic levitation facilities, a 
cryostat, and equipment enabling high temperature processes. Various experiment 
sections or sealed cells would be available to fit into each type of rack for the various 

experiment runs. (1 

It is assumed that the FP/DF will be capable of hosting two simultaneous 
experiments, each under microprocessor control from the Facility rack. In addition, the 
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Facility rack will perform support functions such as on-board data and video 
processing Both racks will require interfaces for electrical power, ECLSS air-cooling, 
TCS interfaces for cold-plate-cooled and integrally cooled hardware. The Experiment 
rack will require PMMS interfaces for a variety of fluids and to vent waste fluids. 

The FP/DF simulator will have interface requirements to power, environmental 
control, and PMMS subsystem simulations. Data simulation will be required for 
housekeeping status data such as electric current, flow rates, and temperatures. The 
simulator must support training functions for the Power Control System, Process 
Controller, Data Recorder and Video System. Based on these factors, and the required 
support and control functions for the experiments, the Fluid Physics/Dynamics Facility 
simulator is considered to be complex with respect to the SCS load. In addition 
of the five potential experiment types is considered to provide an additional SCS load 
of simple complexity. 

Modular Co mbustion Facility - The Modular Combustion Facility (MCF) will 
accommodate experiments to help develop understanding of the fundamental theories 
of combustion processes and phenomena, and to provide data helpful to combustion 
related applications such as spacecraft fire safety. The facility will consist of a Facility 

rack, and one or more Experiment racks. 

The Facility rack will house the user support systems, including a DMS data 
interface capable of communicating 160-250 kbps telemetry downlink, and 20kbps 
uplink The Facility rack will also enable high resolution, high frame-rate video data 
(2100 mbits/sec bursts). Experiment control will be primarily from the Element Control 
Workstation, with occasional local control at the facility using a portable MPAC. 

The Experiment rack(s) will be interchangeable, each housing a specific 
experiment type. Potential racks could include a Combustion Chanmber and a very 
low speed Combustion Tunnel. Various sets of combustion apparatus for the 
Chamber, and test sections for the Tunnels would be available for the various 

experiment runs. . . . * 

It is assumed that the MCF will be capable of hosting one experiment at a time, 
under microprocessor control from the Facility rack. In addition, the Facility rack will 
perform support functions such as on-board data and video procassing. Both racks wil 
require interfaces for electrical power, ECLSS air-cooling, TCS interfaces 
plate-cooled and integrally cooled hardware. The Experiment rack will require PMMS 
interfaces for a variety of fluids and to vent waste fluids. 

The MCF simulator will have interface requirements to power, environmental 
control and PMMS subsystem simulations. Data simulation will be required for 
housekeeping status data such as electric current, flow rates, and temperatures. The 
simulator must support training functions for the Power Control System, Process 
Controller, Data Recorder and Video System. Based on these factors, and the required 
support and control functions for the experiments, the MCF simulator is considered to 
be complex with respect to the SCS load. In addition, the two types of experiment 
setups is considered to provide an additional SCS load of simple complexity each. 

Commercial Va por Transport Facility - The Vapor Crystal Facility consists of multiple 
special gradient furnaces with individual micro-processor control for production of 
diffusion gradients and vapor transport. The facility has data requirements of 800 - 
4000 bits/second and includes more than 50 analog temperature, pressure, and other 
housekeeping parameters from four simultaneously operating experiments. The 
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simulator must support training functions for the microprocessor/controller with display 
and keyboard, video/fiber optical diagnostic system, gas/vacuum distribution and 
control system, and the heat rejection/cooling system. The microprocessor unit 
interfaces with thermal and pressure transducers, power supplies, gas supply solenoid 
valves, purge solenoid valves, and cooling loop control valves. It is capable of storing 
operational parameters and varying the power to the heating elements to maintain t e 
desired environment. The optical diagnostic system includes a stereo microscope, a 
hiqh resolution video camera, and light scattering devices. The facility will support four 
simultaneous experiment operations and thus includes four microprocessors, four hea 
exchangers, and one optical diagnostics system. 


Based on these factors the Vapor Crystal Facility is considered to be a complex 
simulator with respect to the SCS load. In addition each of the 4 individual expenment 
microprocessors is considered to provide an additional SCS load of medium 
complexity each. 


Commercial Organic and Polymer Crystal Growth Facility - The Organic and Polymer 
Crystal Growth Facility (OPCGF) will provide a standard interface and support or a set 
number of NASA or customer-supplied growth modules. These modules will enable 
the growth by various means, of organic and polymeric crystalline materials. I he 
facility will provide power, confinement, and the capability for materials processing, 
data acquisition and recording, control, and diagnostics. The facility consists of a 
double rack of equipment, including 4 experiment modules, a control unit/recorder, 
and a melt-growth furnace containment. It is assumed that the facility win 
accommodate two simultaneous experiments at one time. Data downlink is estimated 

in the range of 1-5 kbits/sec. . omto 

The simulator for the OPCGF will include interfaces with power and PMMb 
subsystem simulations. It will simulate the processor/controller/recorder functions and 
based on the small telemetry flow, will have to simulate a relatively small number of 
operational and status parameters. From these factors, the OPCGF simulator is 
considered to be of medium complexity with respect to the SCS load. In addition each 
of the 4 individual experiment processors is expected to represent an additional SCS 
load of simple complexity each. 


Commercial Float Zone Facility - The Commercial Float Zone Facility (CFZF) consists 
of a single rack containing two axial tube furnaces with temperature capabilities up to 
1600 deqrees C. Between the two tube furnaces is an independently-controlled high 
temperature zone capable of up to 2200 degrees C. The furnace system is capable of 
holdinq a sample just below its melting point, except for a molten zone in the center 
which can be translated along the sample length by the movement of the furnace. Data 

generation during a run is estimated at 250 bps. . 

The CFZF simulator will provide interfaces to the power, PMMS, and 
environmental control subsystem simulations. It will simulate the processor/controller 
functions of the facility and a small number of housekeeping parameters. Based on 
these factors, the CFZF is considered to represent a load of simple complexity to the 

SCS. 


TFCHNOLOGY FXPERIMENTS 
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Quantized Vortex Structures in Superfluid H e li um - This experiment will investigate the 
formation and distribution of quantized vortices in freely suspended rotating drops of 
superfluid helium. An acoustic suspension system will be used to suspend a drop of 
liquid helium within a cryostat at 2 degrees Kelvin. While rotating the drop, vortices 
within the drop will be observed optically with low and high resolution cameras. 
Nominal data generation rates are estimated at 100 kbps. The experiment functions 
include: 

Cryogen Facility controls 

Cryostat control 

Acoustic Suspension System controls 

The simulator for this experiment must provide interfaces to power, PMMS, and 
environmental control systems. Some simple scene generation capability will probably 
be necessary. The simulator will model the processor/controller functions of this 
experiment and generate a number of housekeeping/status parameters. Based on the 
above factors, this simulator is considered of medium complexity with respect to the 
SCS load. 

Solar Arrav Energy Storage Technology - The purpose of the Solar Array Energy 
Storage Technology (SAEST) experiment is to demonstrate various power system 
technology applications in space. The experiment equipment, consisting of a power 
experiment application such as an Energy Storage Unit, and a controller/monitor 
panel takes up about 60% of one rack. Nominal data generation during an experiment 
run is estimated at 1000 kbps for 20.4 hours. The simulator for this experiment will 
generate some housekeeping parameters of the experiment, and simulate the control 
and monitor functions, possibly interactive with table-generated science data. Based 
on these factors, this simulator is considered to be of medium complexity with respect 
to the SCS load. 

Surgerv Torhnninnv Development - The purpose of this experiment is to develop a 
surgical module, and surgical procedures effective in microgravity. Experiment 
hardware will take up two racks and consist of a surgical table, patient, doctor, and tool 
restraints; a fluid containment system, lighting, fluid suction apparatus and surgical 
implements. The facility will probably be composed of Pl-supplied equipment, 
requiring little or no simulation support. There are no apparent data communication 
requirements with the ground, so simulation of housekeeping data parameters are not 
a concern. All data collection will be handled with Lab Support Equipment or facilities 
of the Surgery Technology Experiment. Therefore, this experiment is not considered to 
represent a significant simulation load to the SCS. 

LIFE SCIENCE EXPERIMENTS 

The Life Science Experiments are not anticipated to, in general, require any 
simulation capability from the SCS. They will mainly involve measurements of 
crewmembers' physiological characteristics, dissection of lab animals, and other 
activities involving Lab Support Equipment whose load on the SCS has been 
calculated in Study T-4. Many experiment simulators will consist primarily of PI- 
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supplied equipment requiring relatively little simulation support. Exceptions are noted 
below: 

Hahitai Hnldmn Svstem - The rodent habitat equipment will have some environmental 
support tv^ aSSiteters which may require simulation via the SCS. Types of 
data that shall be acquired, processed, and made available for monitoring will include. 

• The amount of food and water consumed, and the amount of physical activity 
performed by the specimen. 

. Excess water indicators which monitor the water distributed to the system. 

• Critical instrument temperatures and humidity measurements. 

• General housekeeping data of the RAHF. 

This eauioment is considered to be similar to the Spacelab Research Animal Holding 
Facility (RAHF) experiment and is considered a medium complexity experiment with 

respect to the SCS load. 

Rinmnanerative Lila Suppefl Easily - The purpose of this experiment is to determine 
To, 6 aTo-g. There will be int^h, 

environmental control. In addition, the simulator will probably generate ®^^° n n r ^ Sf' 
suoDOrt type data parameters for the habitats. Based on the above factors this 
experiments estimated to represent an additional SCS load of medium complexity. 

ATTACHED PAYLOADS 

nunPmi r Stabilization Free Flvino Robot - The goals of this experiment are to evaluate 
techniques of dynamically stiffening the relative position and orientation of ® r ^ e ' 
robot whfle slicing another flying article. Another goal is to characterize the dynamic 
intpr^rtions of two moving obiocts in a zero-g environment. 

Th"s experiment will use a free-flying robot and two test articles. The robcrt wi« 
nprform samole operations such as module replacement on the test articles, while the 
SertTmancetf ite positon and attitude stiffening control system will be measured, as 

Wi " ^T^etTperimem^p^ with which the crew will interact during the 

exoeriment includls data processors. CRTs, data recorders, signal analyzers 
monitnr/rnntrol units etc Typical IVA tasks will include monitoring the robot, providing 

according data. Besides the specialized expenmen, 
nonoiQ 9 thP exDeriment requires the use of the Telerobotics Workstation, the APAE 
Workstation and the OMV Workstation. There will be nominal data-flows of 90 kbps for 
^nwnBnk 10 kbos for uplink 20 kbps from Station to Free Flyer, and a video link from 
?he Free-FlyeMo The Staton There will be an interactive audio link between the 

Station and Ground. 
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The simulator for this experiment must supply interactive video data, operations 
of signal analyzers and monitor/control functionality. There will be interactive man-in- 
the-loop type simulations necessary. A significant number of housekeeping 
parameters will have to be simulated. Based on the above factors, this simulator is 
considered to be complex, with respect to the SCS load. 

Optical Spatial Tracking Spacecraft - The Optical Spatial Tracking Spacecraft (OSTS) 
is an experiment which will verify the accuracy of current super resolution optical 
techniques of locating distant spacecraft. The experiment will verify the operability of 
the technique's measurement capability, and assess the impact of the Space Station 
environment on that capability. 

The primary experiment equipment will consist of externally mounted 
optical/electronic instruments which will be focused on two OMV-mounted laser 
sources. The control and observation equipment for this experiment will be contained 
in a half rack in the US Lab at a specialized experiment panel. The OMV Workstation 
will be used to maneuver the OMV, while the APAE Workstation will be used for 
external payload-common activities such as data routing. While configuration of the 
specialized experiment panel is not yet well defined, it will probably consist of controls 
and displays sufficient for: 

Pointing of optical instruments 
Power control 
Video recording 
Data recording 

Data communications with the earth are estimated at 1000 kbps downlink and 
32 kbps uplink, plus interactive audio communications. Pointing experiments of this 
type usually require a lot of computer simulation support, due to the man-in-the-loop, 
interactive type of simulations necessary for training. In addition, a significant number 
of housekeeping parameters will probably need to be generated. Based on these 
factors, this simulator is considered to be complex with respect to the SCS load. 

Spacecraft Strain and Acoustic Sensors - This is an external experiment, requiring 
little crew interaction, beyond a very small amount of monitoring at the experiment 
panel. The simulator will be required to generate housekeeping parameters for the 
experiment sensors and equipment, and provide nominal science data values to an 
instrument or display. Based on the above factors, this experiment is considered to be 
of simple complexity with respect to the SCS load. 


Others - The following external experiments, while considered part of the Mission 
Utilization Study payload complement, do not represent a unique load to the SCS, 
since their operation will be controlled from Station systems: 


Low Acceleration Propulsion Technology 
Microelectronics Data System Experiment 
Advanced Structural Dynamics and Control 



TRW-SCS-89-T2 


Analysis 14 


SS Pavload Review aM Qlassificalim Summa iE - The above described 
analysis of a typical SS payload experiment complement indicates the following 
mixture of payload simulators will be required for a single SS mission increment. 


U.S. Lab 

Attached Payloads 


Complex 

5 

2 


Medium 

10 

Q 


Simple 
25 
1 


Tota l 
40 
2 


Total 


7 


10 


26 


43 


These numbers represent the load required for the individual ®*P en ™f , n * 
oavload simulators In addition host service software tasks will be required to pro 
the total simulation environment. The Spacelab payload training environment can be 
used as a rebresentative example of the additional host system overhead required to 
provide the total simulation environment. The following is an example list of Spacelab 
PCTC host system level tasks. 


O FT- Operator Control Task (OCT) Initialization Task 

ACP - Asynchronous Command Processor 

AKP - Asynchronous Keyboard Processor 

SDP - Simulation Display Processor 

AMP - Asynchronous Message Processor 

SS0-SS4 - Synchronous Task Schedulers 

ECPREP - Experiment Computer Preparation Task 

GMT - Time Generation Task 

ECOSO - Command Processor 

ECOS1 - Keyboard Message Processor 

ECOS2 - Display Processor 

ECOS3 - Timeline Services Task 

ECOS4 - Exception Monitoring Task . . .. , 

KBDSERVx - Keystroke Processor Task (one for each workstation) 

DSPVS11 - Display Servicer Task 

XTLM - Timeline Maintenance Task 

XTMN - Timeline Monitor Task 

ENV - Orbiter Environment Model 

EPDS - Electrical Power Distribution Simulator 

HRZS - Horizon Sensor Simulator 

VTR - Video Tape Recorder Simulator 

VAS - Video Analog Switch Simulator 

OFD - Orbiter Flight Data 

PTC - Payload Thermal Control 

PLSS - Payload Status Simulator 


In the Spacelab training environment these types of host level tasks provide an 
additional computer system execution load of approximately 48,200 lines of code and 
2500 K bytes of memory. Note that the development load for the host system task 
could be considerably higher (up to 220,000 lines of codes) ^ 
various library routines and tasks that would not be required to ' execute dunng a 
training session. All of these tasks would be required to execute in a one second 
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pxprution cvcle. In addition to these host level requirements, some level of software 
simulation of DMS capability may be required. If, for example, DMS components wer 
late or unavailable a DMS simulation would be critical. For estimating purposes t 
level is assumed to be approximately the same as the host system level load 

described above. 


To determine the SCS load in terms of memory requirement 5 and lines of code^ 
comDarable Spacelab payload experiments were used as a benchmark . 
following table shows some size requirements for typical Spacelab payload models. 


Model 

HUT 

WUPPE 

UIT 

IMCS 

JOP 

A7PNL 

OFD 

1ES013 

1ES016 

1ES017 

AEPI 

SEPAC 

ISO 

FAUST 


Complexity 

Complex 

Complex 

Complex 

Medium 

Medium 

Simple 

Simple 

Complex 

Simple 

Simple 

Complex 

Complex 

Simple 

Simple 


Lines of Code Memory Require ments^ ttyl£3) 


47.300 

49.300 

44.900 
21,100 

22.900 
4,200 

11,400 
26,100 
1 1,400 
6,400 
16,600 

24.000 
3,100 
6,400 

34,700 

22.000 
7,150 


172 

180 

151 

90 

120 

47 

102 

402 

193 

154 

454 

513 

106 

92 

312 

105 

116 


Average Complex 
Average Medium 
Average Simple 

Usina these average numbers and the above payload model classification list 
provides a 9 totll SCS load for the US Lab and Attached Payloads (a comb.ned 
payload training configuration) of: 
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Lines of Code Memory Requirements (K bytes) 

7 complex models @34700 = 242,900 @312 = 2,184 

10 medium models @22000 = 220,000 @105= 1,050 

26 simple models @71 50 = 185,900 @116 = 3,016 

Host system tasks = 48,200 = 2,500 

DMS S/W Simulation = 48,200 = 2,500 

Combined P/L Total 745,200 11,250 

If we assume that the combined Columbus/JEM module payload complement 
would be approximately equal to the US Lab SCS load we can estimate the total SCS 
load for one SS consolidated increment as follows: 

Lines of Code Memory Requirements (K bytes) 

14 complex models @34700 = 485,800 @312 = 4,368 

20 medium models @22000 = 440,000 @105 = 2,100 

52 simple models @7150 = 371,800 @116 = 6,032 

Host system tasks = 48,200 = 2,500 

DMS S/W Simulation = 48,200 = 2,500 

Increment Total 1,394,000 17,500 

Based on the assumption that a part task trainer will support one third the 
payload complement (plus the system overhead) of a combined payload trainer 
complement, the following numbers can be derived for a part task trainer: 

Lines of Code Memory Requirements^ bytes) 


2 complex models @34700 

= 69,400 

@312= 624 

3 medium models @22000 

= 66,000 

@105= 315 

8 simple models @7150 

= 57,200 

@116= 928 

Host system tasks 

= 48,200 

= 2,500 

DMS s/w simulation 

= 48,200 

=2,500 

Part Task Trainer Total 

289,000 

6,867 
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Figure T-1.1 shows the PTC Training Increment Flow Requirements for all the 
SS missions that will be in the training flow at one time. From this figure it can be seen 
that the PTC must support crew training on 4 different missions simultaneously. This 
will include one full consolidated increment training configuration, one combined P / 
training configuration, and part task training or individual P/L training on experiments 
from two other increments. The baseline assumption is that there can be three part 
task training configurations operating simultaneously for the purpose of training. 
Others will be operating for simulator development, simulator l&T, simulator V&V, and 
simulator maintenance. Also shown is the POIC training in payload operations that 
must be supported. The above estimates and the PTC training increment flow 
requirements from Figure T-1.1 can be used to determine a total SCS training load 
requirement as follows: 

Lines of Code Memory Requirements (K bytes) 


1 Consolidated @1,394,000 
Increment Configuration 

= 1,394,000 

@17,500 = 17,500 

1 Combined P/L @745,200 
Configuration 

= 745,200 

@11,250 = 11,250 

3 Part Task @289,000 

Configurations 

= 867,000 

@6,867= 20,601 

1 POIC Configuration 
(7 consoles) 

1,394,000 

@17,500 = 17,500 

SCS Training Total 

4,400,200 

66,851 


Launch Number 1 2345678910 Le 9 end 
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FIGURE T-1.1 PTC TRAINING INCREMENT FLOW REQUIREMENTS 
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Results 

1. The SCS (to determine the training portion of the load on the system) shall 
support the simultaneous execution of 6 independent training systems (1 fuN 
consolidated increment trainer, 1 combined payload trainer configuration, 1 set of 7 
POIC training consoles all running the same increment, and 3 part task trainers). 

2. An increment trainer can be assumed to consist of a total of 1,394,000 lines of 
code and 17,500 K bytes of memory. 

3. A combined payload trainer configuration can be assumed to consist of a total 
of 745,200 lines of code and 1 1 ,250 K bytes of memory. 

4. A part task trainer can be assumed to consist of a total of 289,000 lines of code 
and 6,867 K bytes of memory. 


Open Issues/Notes 
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Study Title: Impact of OMS Training Support on PTC 

Study No. T-3 Report Version: 2 


Problem 


The PTC will train flight and ground crews in payload management activities 
which require the use of OMS functions for their proper execution. The impact on SCS 
requirements of providing the necessary OMS functionality and training must be 

determined. 


Approach 

An analysis of OMS functions will be performed to determine their effect on the 
SCS functions of training, development, and operations evaluation While detailed 
OMS responsibilities for payload management are not ye] available, t0 P J eve ' 
functional requirements have been defined for general OMS operations. These 
requirements will be individually assessed to determine the impact on the SCS 
configuration of providing appropriate training for their payload-related aspects. 


Analysis Overview 

The Operations Management System (OMS), will provide management of 
operations requiring coordination between Space Station Systems, Elements, 
Payloads, and the ground and flight crews. The OMS will be composed of onboard 
application software (the Operations Management Application (OMA)) resident in the 
DMS as well as ground application software (Operations Management Ground 
Application (OMGA)). For training purposes, the OMA software functions are assumed 
to be provided by supplied DMS kits. The OMGA functions may have to be simulated 

by the SCS. 


DMS kits and their effect on SCS requirements have been considered in study 
A-10. This study will assess only the impact of OMS-unique payload management 
training requirements on the SCS configuration. 


Inputs 

1. SSP 30000 Space Station Program Definition Requirements Document, 
Section 3, Revision G 

2. JSC 32060 Space Station Training Facility (SSTF) Level A Simulation 
Requirements 

3. SSP 30261 Architectural Control Document, Data Management System, 
Revision B, Feb. 19, 1988 
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Assumptions 

3. OMS functionality with respect to the onboard application (OMA) will be 
provided by the flight software resident on the DMS kits. OMS functionality with 
respect to the ground application (OMGA) will not be a part of the DMS and will 
have to be provided by other means. 

Analysis 

The primary purpose of the PTC is to provide training in payload operations. In 
order to do this however, it is also necessary to teach the utilization of support and 
implementation systems ancillary to payloads (such as the OMS). Since it is assumed 
that trainees will receive basic instruction elsewhere on these systems, PTC instruction 
will most likely be strictly procedural in nature, involving system tasks directly 
supportive of the payload activity addressed. The problem then, is not so much to 
determine the impact of providing training for payload-unique OMS functions, but 
rather the impact of providing the simulated OMS environment which will be necessary 
for the execution of simulated payload operations. 

Since the OMGA is not expected to be hosted on the DMS, it will not be 
available on a DMS kit. This means that the OMGA functions will be derived either 
from a WP-02 simulation, an SCS-developed simulation, or the actual ground 
software. OMA functions on the other hand, will be derived from the software resident 
on the provided DMS kits. For both parts of the OMS, consideration must be made for 
the SCS requirements to interface, integrate, and operate the required OMS/DMS 
functionality. 

OMS top level functions are analyzed to determine the necessary interfaces 
with the flight crew, ground crew, payloads, and SS systems which must be simulated 
in the PTC. A review of OMS documentation shows that the OMS is currently expected 
to provide the following services: 

1. Manage and update the short term plan 

2. Coordinate systems, payloads, and crew operations in execution of the 
short term plan 

3. Monitor systems and payload status 

4. Manage inter-system testing 

5. Maintain and log global configuration, activity, and state information 

6. Detect and manage resource conflicts 

7. Manage global base caution and warning 

8. Perform global base fault management and reconfiguration 

9. Support transaction management 

10. Provide global base inventory and maintenance management 

11. Support onboard simulation and training 

The level of detail available for the above activities is insufficient to allow their 
decomposition into payload related and non-payload related components. Analysis of 
the above services however, does yield the minimum dataflows and interfaces 
required for the OMS to accomplish its payload-related tasks (see Figure T-3.1). Figure 
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T-3.2 consolidates those dataflows and depicts the interfaces, implemented with SCS 
simulations and a DMS kit. 

Major interface #1 links onboard and ground OMS software via the C&T system. 
Onboard OMS can be simulated by the flight software resident in the DMS kit. The 
ground OMS however, as well as the linking C&T function (or data transformations 
necessary to mate OMGA software with the DMS flight data streams), must be 
provided by the SCS. 

Major interface #2 links the OMS with the flight crew workstations. Since the 
crew workstations are included as part of the DMS kit, no SCS interface is required. 

Major interface #3 links the OMGA with the other POIC functions. This interface 
is internal to the SCS but for fidelity may have to be implemented in a manner 
analogous to the real world application, the details of which are not currently defined. 

Major interface #4 links the OMA with SS payloads, elements and systems. At 
the PTC, this refers to the interface between the DMS kit and SCS-resident 
simulations as well as to flight or flight-equivalent hardware/software. While 
communications between these simulations and the OMS will require special SCS 
interfacing, most of this effort is due to the necessity of linking with the DMS kit, rather 
than a unique requirement imposed by the OMS. It is likely however, that more fidelity 
will be required of the SS subsystem simulations in order to provide the OMS with the 
data necessary for the execution of its management functions. 

Results 

These study results are based on the most current OMS information available. 
There are however, efforts being made to more fully define the payload management 
role of the OMS. A NASA study, in conjunction with McDonnell Douglas and TRW has 
been recently initiated to determine requirements in this area. Immediate efforts are 
also underway to redefine plans for POIC-resident software, including the OMGA. The 
SCS study will track developments in these areas and assess their impact on SCS 
requirements. 

Tr ai ning 

In order to train payload operations which require OMS services: 

1. An OMGA simulation, and its interface with the DMS kit and the other POIC 
functions must be provided. Since preliminary estimates have sized the onboard OMS 
at 2. 5-3. 2 MIPS and 14.4-21.0 MB of memory, and considering that one function of the 
OMGA is to serve as an OMA backup, the load on the SCS imposed by the OMGA may 
be assumed to be about 3.2 MIPS and 32 MBytes of common storage (not including 
the DMS interface, which would have to be provided in any case). 

2. SS simulations executed in the SCS will need to be more complex in order to 
supply the data and response required by the OMS management functions. An 
increase in complexity (and resultant SCS load) of at least 20% for each module is 
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foreseen over that needed to satisfy strictly payload requirements. It is not certain 
however, if this represents an increase in the fidelity requirements already envisioned 
for SS system simulations (reference Issue T-5). In the case of payload simulations, 
command/response requirements would be unaffected by the presence of an OMA 
interface and experiment data streams could still be statically simulated; therefore no 
significant increase in complexity over that already estimated (Issue No. T-6) should 
be necessary. 

Development 

1. Greater effort will be necessary to develop, integrate, and interface system 
simulations with the DMS kits, due to the additional data flow required by OMS 
functionality (see #2 above). This is seen as a one-time requirement which should not 
affect the SCS development configuration. Consideration should be given though, to 
the steady-state effort required to maintain these simulations as the SS evolves. 

2. While additional effort must be made to develop the OMGA and its interfaces 
with the DMS kit and the other POIC functions, this is also seen as a one-time 
requirement which should not affect the SCS development configuration, though 
consideration should be given to the steady-state effort required to maintain these 
simulations as the OMS evolves, as well as the greater computational capacity 
required to execute the OMGA during development activities. 


Operations and Evaluation 

1. As noted in SCS Issue No. T-3, since crew and ground procedures can be 
expected to be heavily oriented toward the use of payload OMA functions, a high 
fidelity simulation of these functions (or the use of actual OMA flight software) will be 
required to support procedure development and verification. Additionally, the testing of 
maintenance procedures on flight-equivalent hardware will require a high fidelity 
representation of the OMS maintenance management function. These requirements 
may be satisfied by the OMS functionality already described above for the Training 
and Development functions. No Operations Evaluation-unique OMS capabilities 
should be needed. 
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Study Title: Scope of Integrated Core Subsystem Training in PTC 

Study No. T-4 Report Version: 3 

Problem 


The load on the PTC simulation computer system due to subsystem simulations 
must be quantified in order to determine the maximum loading on the SCS at any 
given time to support payload training. Since the PTC has no responsibility for 
subsystem training, the load due to subsystem simulations will only be related to what 
is required to support payload operations training. Since payload simulators must be 
transportable to the SSTF to support integrated SS training it will be necessary for the 
payload simulators to interface with the SSTF subsystem simulators. Therefore there 
will be an SCS load due to payload/subsystem integration and in some cases 
subsystem simulators will have to run on the host SCS to support payload training. 

Approach 

The WPOl Trainer Development Plan will be reviewed to determine the current 
anticipated relationship between subsystem and payload simulators. Past experience 
with Spacelab subsystem simulators in the Spacelab Simulator at JSC will be utilized 
to determine potential SCS load. 

Analysis Overview 

The WPOl Trainer Development Plan indicates that simulated payload interface 
will be required for such US Lab subsystems as the Vacuum Vent System, 
Acceleration System, MPSG, Mass Energy Analysis (MEA), and the Process Material 
Management Subsystem. The WPOl Trainer Development Plan further indicates that 
no simulated payload interface is required for common subsystem simulations such as 
the Environmental Control Life Support System and the Thermal Control System. 
However Spacelab experience dictates that this might not be true. Hooks to simulate 
the payload load on the Environment Control System, Thermal Control, and Electrical 
Power Distribution might be required to provide adequate training on payload 
operations. 

Inputs 

1. D683-1 01 35-1 , WPOl Trainer Hardware/Software Development Control Plan, 

Draft 1 , October 31 , 1 988. 

Assumptions 

4. A worst case load on the SCS is assumed for subsystem models which might 
be required to support payload training. 
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Analysis 

The WP01 Trainer Development Plan defines US Laboratory software 
simulations requiring payload interface for the following subsystems. 

Vacuum Vent System * 

Acceleration System * 

MPSG (General Lab Support Facility) * 

Laboratory Support Equipment 

Preservation and Storage System 

Maintenance Workstation/Lab Sciences Workbench * 

Life Science Glovebox 

Mass Energy Analysis (MEA) Subsystem * 

Equipment Washer/Sanitizer 

Process Materials Management Subsystem Simulation * 

Inventory Management System (IMS) * 

While all of the above listed subsystems are defined as requiring software 
simulators with payload interfaces it appears that many of these systems are actually 
hardware systems that would not be particularly applicable to software simulation. 
Therefore, for the purpose of this study, only those subsystems from the above list 
marked with an asterisk are considered to present any load to the PTC SCS. 

The WP01 Trainer Development Plan also lists the following common 
subsystem simulations. 

Water Recovery and Management System 

Waste Management 

Air Recovery 

ACS 

Temperature and Humidity Control 
Fire Detection and Suppression 
Fluid Flow Loops * 
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Audio/Video * 

Electrical Power Distribution * 

Guidance Navigation and Control* 

Communications and Tracking* 

Even though the Trainer Control Plan does not identify any payload interface for 
most of the common subsystems listed above, our Spacelab experience indicates t 
there will be a payload interlace for the subsystem simulators marked above with an 

asterisk. 

From the above two lists a total of 12 subsystems been , ide + ntifi ®^^ h n a r ! 

potentially will require software simulation on the PTC SCS in order to su PP° d 
paylad operations training. Since the function of the PTC is on y to provide pay oad 
traininq it is assumed that relatively simple low fidelity models is all that wil be 
reared for these subsystem simulations at the PTC. Subsystem training | w be 
supported at the PTC only to the level necessary to operated the payload I and I details 
of the subsystems will not be required for subsystem simulators on the SCS. 
However the interface between the payloads and these lower fidelity sub syst®m 
simulators will need to be the same as the interface to the higher fidelity subsystem 
simulators that will reside in the SSTF. This will be necessary to > rn.nmtze 
modifications to the payload simulators when they are transported to the SSTF for the 
final phase of SS increment training. 

The Spacelab Systems Simulator (SLS) at JSC provides some experience for 
anticipated subsystem simulations that might be required for the SS The SLS has 
nnp rated usina two Perkin and Elmer 832 computer systems. The SLS has provided 
simulations for the Environment Control System, the Thermal Control System t t e 
Electrical Power Distribution System, the Subsystem Computer grating System 
(SCOS), and Igloo systems. Each of these simulations has consisted of from o 
eiqht models. Execution rates for the various models vary from 1 to 25 Hertz. The 
payload interface load to these subsystems has not been dynamically s '^ la ^® d bL j! 
the capability has been provided for the simulation director to manually input payload 
load parameters for such subsystem simulators as the Thermal and Electncal systems. 

For the purpose of this study we will assume that a subsystem simulator will be 
a simple model that will be equivalent in size to a simple payload s '™ u ! at ° r - 1 
estimated size requirements from the Spacelab experience (see Study T-1) provides 
the following requirements for the subsystem simulation load on the SCS. 

Lines of Code Memory Requirements (K bytes) 

12 simple models @7150 = 85,800 @116 =1,392 


Total Subsystem Load 
per Consolidated 
Configuration 


85,800 


1,392 
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II we make the same assumption relative to part task trainers for subsystem 
requirements that was applied to the payload SCS load we would again assume that 
each part task trainer will require one third the load of a full in ^ r ®^® nt ^ ! 9 _ . 
estimates and the training flow requirements that were shown in Figure T-1.1 in stu y 
T-1 (one full consolidated configuration, one combined payload J on j9 u q ratl °^ 
different part task trainers, and 1 POIC configuration) provides a total SCS training 
load requirement for subsystem simulators as follows. 


Lines of Code 

1 Consolidated @ 85,800 = 85,800 
Configuration 

1 Combined @85,800 = 85,800 
Payload Configuration 


3 Part Task 


@28,600= 85,800 


1 POIC @ 85,800 = 85,800 

Configuration 

Total Subsystem SCS Load 343,200 


Memory Requirements (K bytes) 
@ 1392 = 1,392 


@ 1392 = 1,392 

@464= 1,392 
@ 1392 = 1,392 

5,568 


Results 

1 The SCS shall support payload/subsystem interfaces for the simultaneous 
execution of 6 independent training systems (1 full consolidated increment t J ai, l e I- 
combined payload trainer configuration, 3 part task trainers, and 1 POIC 

configuration). 

2 The subsystem simulation load on the SCS for a full increment trainer can be 
assumed to consist of 12 simulators containing a total of 85,800 lines of codes and 
requiring 1 ,392 K bytes of memory. 

3 A part task trainer can be assumed to consist of 3 subsystem simulators 
containing a total of 28,600 lines of code and requiring 464 K bytes of memory. 


Open Issues/Notes 
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Study Title: Fidelity of Element Control Workstation (ECWS) 

Study No. T-10; Report Version 2 
Problem 

This study examines the system hardware requirements for representing the 
ECWS with varying fidelity. The implications of using the flight equivalent ECWS and 
an ECWS simulator are explored. 

Approach 

The approach for determining these requirements is to search through 
published reports, extract findings from various working groups, and hold discussions 
with users. 

Analysis Overview 

Requirements for the ECWS, like other SS systems, are not fully defined yet 
However, careful study of published material and presentations, in conjunction with 
user discussions, has provided the information presented below. It must be noted that 
since requirements are not yet solidified, the ECWS description presented below only 
represents the information available at this time, and will likely be changed. 

Inputs 

1 SSP 30261. Rev. B Architectural Control Document, Data Management System 
DMS Baseline, J. N. Dashiell, Nov. 29, 1988 

2. JII-2782-391 3 November D&C Splinter Minutes 

3. D683-1 0001 -2-6 Boeing Proposal, pp 6-21 - 6-24 
Assumptions 

5 The SCS ECWS is not required to provide the nonpayload related functionality 
of the flight equivalent ECWS. However, the flight equivalent ECWS may be used for 
the SCS ECWS. 

Analysis 

ECWS Purpose 

The purpose of the ECWS is to provide the primary user interface, including 
command and control, for payloads. 

ECWS Subsystems 
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The ECWS is composed of the following subsystems: video display and 
recording, audio distribution and recording, caution and warning (C&W) indicators, 
and multipurpose application console (MPAC). The ECWS is interfaced to the 
communications and tracking (C&T) system, the time distribution bus, the C&W system, 
the global and local Core Network, and the payload science network. 

Video Subsystem 

The C&T system is responsible for providing video distribution to the ECWS. 
The video subsystem consists of a 19 inch color monitor, a high quality video cassette 
recorder, and a hand controller for camera control. The VCR has picture processing 
functions such as time display, picture within picture, freeze frame, slow motion, etc. It 
is remotely controllable from the ECWS MPAC. The video subsystem is discussed 
further in Study T-15, Requirements For PTC Payload Video Data. 

Audio Subsystem 

The C&T system is responsible for providing audio distribution to the ECWS. 
The audio subsystem consists of a dual audio cassette recording system, and a 
communications interface to the C&T system. A communications panel for distributing 
audio sources is also provided. 

Caution and Warning Indicators 

The ECWS provides indicators for the Caution and Warning (C&W) System. 
The C&W system also has the capability for a voice annunciation system. 

ECWS MPAC 

The ECWS MPAC consists of a 32 bit workstation (like the IBM PS/2 Model 80) 
with display, keyboard, and a mass storage system with magnetic and optical disk. 
The MPAC will provide access to the DMS, including global and local Core networks, 
the payload science network, and the C&T system. 

ECWS Training Requirements 

The ECWS simulator must in full fidelity mode have the same user interface 
characteristics as the flight system. The external interfaces; command and control, 
data acquisition, and network connections must be compatible with flight equivalent 
systems. A common and flexible user interface provided by the ECWS will simplify 
payload operations. 
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E£W SSL mulator Approach 

When examining the ECWS from a payload operations training perspective, the 
question of requirements for modelling the nonpayload related portion of the ECWS 
arises. This includes the Caution & Warning (C&W) indicators, portions of the audio 
subsystem (perhaps), and large segments of ECWS software. The assumption is 
made that there is no requirement for modelling the nonpayload related functions of 
the ECWS. The options for the ECWS simulator include the following: 

1. Use the flight equivalent ECWS and develop whatever additional capabilities 
are necessary to support simulator operations and payload training. The ECWS, for 
example, may be required to interface with SCS specific equipment in addition to the 
DMS kit. This approach requires early availability of the actual ECWS in time to 
support initial training. 

2. Develop the ECWS simulator as part of the SCS. Implement only the 
functionality required to support payload operations training. There are two 
implementation approaches for the SCS developed ECWS simulator. 


A. Intelligent workstation with resident simulation model and associated 
subsystems. 

B. Terminal and ECWS subsystems controlled by a task on a central 

computer. 

The ECWS simulator configurations identified above are discussed in greater 
detail below. 

Flight Equivalent ECWS Simulator 

The flight equivalent ECWS would provide the highest fidelity simulation and 
should be used, if available. Software to support payload operations training will be 
required. The ECWS simulator software is further discussed in a later section. 

SCS Developed ECWS Simulator 

If the flight equivalent ECWS is not available, the SCS will develop the ECWS 
simulator. There is a wide range of fidelities with which the ECWS can be simulated. 
These ranges of fidelities are discussed below. Only those functions that are related to 
payload operations training will be fully implemented according to the ECWS 
requirements. 
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ECWS Simulator Requirements 

From the ECWS description given above, the ECWS simulator requirements 
can be determined at a high level as constituent subsystems. The ECWS simulator 
will include the following at some level of fidelity. 

1 .Video subsystem. 

2. Audio subsystem. 

3. Caution and Warning indicators. 

4. ECWS MPAC. 

5. Connection to the DMS networks. 

6. Support software to control the ECWS. . . . 

7.Command and control software to interface with payloads as a minimum ana 

possibly with the SS Core systems. 

In addition, the ECWS simulator will include functionality related to training and 
an interface to the Simulation Control System (SCS). 


Fidelity fif ECWS Simulator 

The ECWS simulator can be represented by a wide range of fidelities, 
reqardless of whether or not the flight equivalent ECWS hardware is used^ 
Representative fidelity ranges of low, medium, and high are studied and a range of 
implementation options are presented. Each of the requirements for the ECWS 
simulator described above are studied for these fidelity ranges. The ECWS simulator 
system performance is determined by combining the performance of its component 
subsystems. 


Video Subsystem Fidelity 

The video subsystem of the ECWS simulator is principally responsible for the 
display and storage of payload acquired video data. A range of fidelities for significant 
video subsystem parameters is shown in Table T10-1. The video subsystem may be 
implemented as either a separate set of hardware or simulated on a workstation from 
predefined images stored on disk. 


Audio Subsystem Fidelity 

The audio subsystem of the ECWS simulator enables communications to all 
areas of the SCS. A range of fidelities for significant audio subsystem parameters is 
shown in Table T10-2. 


Caution and Warning Indicator Fidelity 

A range of fidelities for Caution and Warning indicators is shown in Table T10-3. 
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Parameter 


Resolution 


| Screen size 

I 


I 

| Video format 


Remote VCR 
control 


Video switching 


Table T10-1 Video Subsystem 

evels of Fideli 


I 

High | Medium 


2048X2048 

(digital) 

1280X1024 

(digital) 


25 inch 


(1 1 25 line) 


Range of color j 65,536 colors 


Medium 

Low 

| 525 line NTSC 

SSTV 

j (standard video) 

(low rate) 

| 640X350 

320X200 

j 19 inch 

13 inch 

| NTSC video (RS-170A) 
| (525 line) 

| EGA 

CGA 



SCS computer 
resource impact 


Auto control for 
all functions 


Auto switching for 
up to 8 video 
sources 


No impact if fit. 
ECWS used, except 
for sim. video 


256 colors 

NTSC video (RS-170A) 


fixed camera 


manual, front 
panel control 


Manual switching 
for up to 4 video 
sources 


Significant HW/SW 
impact 


16 colors 


no camera 


no VCR 


video from 
workstation 
display only 
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Table T10-2 Audio Subsystem 
l Levels of Fidelity 


Parameter 


Communications 


High 


Full communications 
to all stations, 
PTC, std telephone 
system 


Audio recording 


Dual cassette deck 
w/remote control, 
auto switching of 
audio sources 


Medium 


Low 


Intercom to 
operators 


Manually operated 
tape deck, manual 
source switching 


No dedicated 
system 


Mock-up of 
tape deck 


Communications 
patch panel 


I 


Auto digital 
switching system 


Manually operated 
patch panel 


Mock-up of 
patch panel 


SCS computer 
resource impact 


No impact if flight 
ECWS used 


low HW impact, 
no SW impact 


Minor HW 
impact 
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Table T10-3 Control and Warning Indicator Subsystem 
| Levels of Fidelity 


Parameter 


Controls and 
switches 


Indicators 


High 


Full implementation 
of all controls as 
on flight hardware 


Full implementation 
of all indicators as 
on flight hardware 


Medium 


Implementation of 
payload related 
controls, other 
controls nonfunc. 


Implementation of 
payload related 
indicators, other 
controls nonfunc. 


Low 


Mock-up of 
controls- 
funct. impl. 
in software 


Mock-up of 
indicators- 
funct. impl. 
in software 


SCS computer 
resource impact 


No HW impact if fit. 
ECWS used, low SW 
impact 


low HW and SW 
| impact 


minor HW 
impact, med. 
SW impact 


ECWS MPAC Fidelity 

The ECWS MPAC simulator provides the computation portion of the ECWS 
simulator. It is the primary means for controlling and monitoring the payloads in the 
SCS. A range of fidelities for the ECWS Multipurpose Application Console subsystem 
is shown in Table T10-4. 

FCWS Simulator Software Fidelity 

The ECWS simulator software must provide the functionality of the flight ECWS. 
It must be capable of being configured from the SCS. A range of fidelities for the 
ECWS simulator software is shown in Table T1 0-5. 

Analysis £f ECWS Simulator Fidelity 

Three levels of ECWS simulator fidelity were described above, identified as 
hiqh medium, and low. A simplification of the alternatives presented is to characterize 
the hiqh level of fidelity as the flight equivalent system, the medium level of fidelity as a 
SCS developed emulation of the ECWS, and the low level of fidelity as a partial 
implementation of the ECWS requirements. The medium fidelity SCS developed 
ECWS simulator is envisioned to be architecturally very similar to the flight equivalent 
ECWS The low fidelity SCS developed ECWS simulator, however, has significant 
architectural differences from the flight equivalent system. This is due to the 
implementation of ECWS subsystems in software. Therefore, the low fidelity system 
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actually has greater processing requirements than the other two alternatives. From a 
SCS cost point of view, the flight equivalent ECWS simulator (high level of fidelity) is 
less expensive than the SCS developed ECWS simulator (medium level of fidelity) by 
a considerable margin. The limited functionality version of the ECWS simulator (low 
level of fidelity) is the least expensive of the three alternatives. As stated earlier, the 
use of the flight equivalent ECWS is the most desirable alternative. 
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Table T10-4 ECWS MPAC Subsystem 


_{ Levels of Fidelity 


1 

| Parameter 

— 1 

| High 

1 

1 

| Medium 

J 

Low 

4 — 

1 Processor 

32-bit workstation, 

1 

llmplement simulator 

| 16-bit micro, 


| 3-4 MIPS, 8MB memory, 

j as a task on a 32- 

2MB memory, 

1 

1 

multitasking OS 

j bit minicomputer, 
j shared with other 

DOS 

1 

1 

1 

- 

| SCS functions 
| 


1 

1 

| Display 

I 

1 9 inch color 

1 

| 13 inch graphics 

1 3 inch EGA 

graphics monitor, 

terminal 

j graphics 

1 

1 

| 1024X1024 resolution 

1 

1 

J 

j monitor 

1 

| User interface 

! Keyboard, light pen, 

1 

| Keyboard, light pen 

| Keyboard, 

1 

1 

1 

touch sensitive 
| panels 

l 

1 

1 

J 

mouse 

1 

|Network connection 

j Network interface, 

1 

RS 232 interface, 

j Network 

1 

1 

| fiber optic network 

1 

| 9600 baud 

J 

j interface 



1 

| Mass storage 
| 

j 300 MB magnetic disk, 

1 

| 180 MB magnetic 

| 40 MB disk 

j 2 - 6 GB optical 

j disk, 1 removable 

j drive, floppy 

1 

1 

j removable disk 

j drives 

| 

disk drive 

1 

J 

| drive 

* ■ — 

1 

|ECWS Subsystem 

| IEEE 488, RS 232 

1 

| RS 232, discrete 

I no electrical 

| interface 

1 

| 

1 

J 

j connection 

1 

j SCS computer 

j No HW impact if fit. 

1 

| Medium HW and 

j Medium HW 

| resource impact 
| 

j ECWS used, medium 

j SW impact 

| impact, 

j SW impact 

1 

j Significant 

1 

J 

1 

J 

| SW impact 


1 
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J 


Parameter 


Interface to ECWS 
subsystems 


Interface to SS 
Core systems 


Interface to 
Payloads 


Training support 


SCS computer 
resource impact 


High 


Flight equivalent 
software to control 
subsystem 


Flight equivalent 
software, full 
functionality 


Flight equivalent 
software, full 
functionality 


Flight equivalent 
software, computer 
aided instruction, 
interface to SCS 


Medium SW impact to 
control simulation 


Medium 


SCS developed 
software to control 
subsystem 


Limited interface 
to Core systems 


SCS developed 
software, full 
functionality 


SCS developed 
software, interface 
to SCS 


Significant SW 
impact 



Implement the 
effect of 
subsystem in 
software 


Only those 
l/F reqd. for 
P/L operation 


Full payload 
control, lim. 
audio & video 



Highest SW 
impact of the 
the 3 alt., 
med. HW 
impact 
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Results 

1 . The ECWS MPAC will be the primary user interface to the payload for the SCS. 

2. The ECWS will interface to the SCS executive application through the DMS. 

3. The SCS executive application will be capable of configuring the ECWS. 

4. There may exist some audio requirement for the SCS. 

5. There may exist some Caution and Warning requirement, for the SCS 

6. There may exist some Video Configuration Requirement for the SCS. See 
Study T-15. 

7. The required fidelity of the ECWS is as follows: 

a. ) All displays and controls associated with the ECWS should have the 

same appearance and response characteristics as the flight system. 

b. ) The user interface to the DMS software for those functions required for 

payload training should have the same appearance and response 
characteristics as the flight system. 

Open Issues/Notes 

1. The specific configuration of the ECWS is not clear. For example, will the 

C&W, audio, and video portions of the ECWS be supplied along with the ECWS? 
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Study Title : Support for Interoperable (Remote Executions) Simulations 

Study No. T-13; Report Version 2 

Problem 

The PTC requirement for support of remote operations could range from no 
remote operation capability of the PTC simulators to a full simulator control and trainee 
interfaces from remote locations such as PI sites. 

Approach 

The study will determine the requirements of the SCS to support interoperable 
simulations. The approach for determining these requirements is to search through 
published reports and conduct interviews with personnel currently working on training 
systems with similar purpose. 

Analysis Overview 

An examination of various remote site possibilities and their affects on the SCS 
design ( interfaces and distributed processing requirements) was performed. 

I nputs 

Assumptions 

Training done via remote execution is either on the SCS remotely, or the 
trainees come to MSFC and train here. Thus, the computing load would be the same, 
and will be accounted for in the study. 

Analysis 

This study provides additional insight into the affects of remote operations 
capability on the SCS system design. The affects are determined by examining the 
various remote site possibilities that might be required in conjunction with the SCS. 

The remote possibilities can be categorized into three groups. A discussion of 
each category is below. 

1 . Trainees at PTC and simulators at PI remote sites. 

2. Trainees remotely trained at their local sites. 

3. PI remotely developed software using SCS provided data. 


Category 1. involves a trainee operating a PTT at the PTC. The trainee might 
find it useful to train using a Pi’s home site simulator. Two possibilities immediately 
arise from this scenario. First, an experiment would be performed at the local Pi's site 
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and the results would be uploaded to the SCS tor storage in a file or files. This data 
then could be reviewed at a later time by a trainee. Second, an instructor would 
initiate and guide the experiment from the PTC with the trainee (also at the PTC) 
responding to the generated results at a workstation. 

The above situations are not practical and produce problems. In the first 
situation reviewing a set of results in many cases after the fact would not provide 
enough training to warrant the effort. In the second situation, the PI s simulator is 
offsite and the trainee would not have access to the C&D panel for hands-on training. 
As a result, only some payloads, in particularly those that do not require trainee hands- 
on responses, could be utilized for training in this manner. Since a full training 
capability is not practical, these possibilities are very poor candidates to be considered 
in the development of the requirements. 

In category 2, training may be remote to the PTC. A remote training capability 
would make the PTC simulators and training capability more accessible to trainees by 
potentially providing training at their home sites. Training of this type should be limited 
up to and including the PTT level. Consolidated training would have to be performed 
at the PTC. The usefulness of this remote training technique will be limited unless the 
local workstation is a duplicate of the PTT workstations so that a DMS kit can be 
attached to the local workstation, or a DMS simulation utilized on the workstation. The 
DMS kit might provide the communication interface to the host of the PTC PTT's. An 
interface of this type creates a remote PTT, which would serve as one of the PTC PTTs. 
Thus reducing by one the number of PTTs at the PTC, but maintaining the total 
acceptable number of active PTTs in general. If the workstation local to the trainee is 
not a PTT duplicate, then a specialized DMS kit or DMS simulation will need to be 
developed in order to complete the interface. This could be a costly investment. 

Category 3 does not involve training as was apparent in the other two 
categories. Instead it involves prototyping and development at a local PI site. For 
example, a PI desires to test prototype software he developed to execute on his 
hardware configuration using SCS supplied data. In this situation a data downlink to 
the local PI facility would prove to be a necessary feature. Irregardless, it is important 
to note that contrasting the capability to download data is the capability to upload data. 
In category 1 the capability to upload data results from a remote execution and is a 
necessity. However, in category 3 the capability to upload data could prove 
detrimental. Unless the constraints are very tight, uploading remotely developed 
software could bypass any configuration management scheme an thus damage any 
PTC baseline. Therefore, precautions should be taken to prevent any problems that 
could occur by uploading remotely developed software. 
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Results 

Allowing training on remote simulators from the PTC is not practical and can not 
be validated for all possible simulators. Therefore, the possibilities described in 
category 1 are poor candidates to be considered in the development of requirements. 

Home site training is not practical if the local workstation is not a duplicate of a 
PTT, because specialized DMS kits or DMS simulations would need to be provided 
and this would be a costly investment. 

Candidate Requirements 

The SCS shall provide a capability to interface with remote training. This 
training shall be restricted to home site training. Home site training have the following 
characteristics: 

- Training shall be limited to the PTT level. 

- The local workstation shall be counted in the total acceptable number of 
active PTTs. 

- The local workstation shall be a duplicate of the PTT workstation. 

- A DMS kit or DMS simulation shall be used with the local workstation as it 
would with a PTT at the PTC. 

The phrase "capability to interface" includes any multitasking operation system or 
distributed computing system necessary. 

The interfaces to remote execution sites shall provide the capability to 
download data from the PTC to the remote site and shall provide the capability to 
upload data from the remote execution site to the PTC. 


Open Issues/Notes 
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Study Title: Requirements For PTC Payload Video Data 

Study No. T-15 Report Version 2 

Problem 

Payload video data will be required for SCS training. The level of fidelity and 
the type of video data required need to be determined. Requirements for putting 
digitized video data into a data stream must be determined. 

Approach 

The study will determine the requirements of the SCS to support payload video 
data for training. The requirements are determined by searches of published reports, 
findings from various working groups, and discussions with users. 

Analysis Overview 

Video is used for SS payload operations to enable the SS crew and ground 
personnel to monitor experiments. The video data is recorded, providing a permanent 
visual record of the experiment. The recorded video data can be subsequently 
analyzed, allowing greater understanding of the experiment. While many of the bb 
experiments are performed in one of the laboratory modules (USA, European, 
Japanese), experiments may be performed anywhere inside or outside the Space 

Station. 

The video requirements for the SS are implemented by the video subsystem of 
the Communications & Tracking system. Video cameras are located strategically 
throughout the Space Station. These cameras are remotely controllable from various 
points within the SS including the ECWS. Also, external video sources such as 
teleconferencing and playback are supported by the video subsystem. The SS video 
data is distributed through a broadband network, similar to a CATV system. 


Inputs 

1 SSP 30260, Rev A Architectural Control Document, Communications and 
Tracking System 

2. Msg 0JII-2782-291 3 November D&C Splinter Minutes 
Assumptions 

6. The SCS video system will be compatible with the video subsystem of the SS 
Communications and Tracking system. 

7. The SCS video system will be capable of interfacing to the SSIS network. 

8. The SCS video system, while compatible with the SS video subsystem, is not 
required to provide 100% of the functionality of the SS video subsystem. 
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9. SCS video data is not required to be digitized and sent through the C&T system 
to the POIC. 

Analysis 

Video Requirements For Training 

The video requirements for training in the SCS at a high level are as follows: 

1 .Familiarize crew and ground personnel with video system operation relative 
to payloads. 

2. Monitoring and recording of experiments. 

3. A realistic visualization of payload and experiment progress where flight 
payload or mock-up is not available. 

Video data from the SCS will not be digitized and transmitted to the POIC 
through the C&T system. However, if it is determined that payload video is critical to 
POIC operation, video data may be distributed to the POIC through a CATV system. In 
addition, the POIC trainers in the SCS will have access to payload video data through 
the SCS video distribution system. 

Video Sources For Pavload Training 

The following are potential video sources for payload training. 

1 .Video camera. 

2. Playback from video recorder. 

3. Video images, still or animated, from mass storage such as optical disk. 
Pavload Video Data 

The payload video data, which drives each of the above video sources, may be 
generated in the following ways. 

1. Video camera monitoring the flight or simulated payload. 

2. Video camera monitoring photograph of payload. 

3. Computer generated scene. These scenes may be still or animated. 
Computer generated video data is discussed further below. 

The specific requirements for payload video data will be determined for each 
experiment. For some experiments, video data is of minor importance for training. For 
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these experiments, static video images may be displayed or none at all. For other 
experiments, dynamic video data may be critical to crew training. 


In some instances video data may be important for training but not available 
from the payload. In this case the video data may be simulated through 
techniques. V The animation need only show those portions of the experiment in detail 

that are of prime importance. 


Computer Generated Video DslS 

ComDuter generated video data can provide a wide range of functionality. At 
the low performance end of the spectrum, static images may be displayed which show 
onlv the minimum tevel of detail required lor training. At the high performance end of 
me soectmm graphics engines may be deployed to generate high resolution .mages 
with realistic motion in 3D using solid modelling techniques The ^ 

video interactive (DVI) technology may also be appropriate. Using DVL seque t 
video images with lull motion and audio are displayed under computer ’ oomroh 
niftorpnt qpnments are displayed depending on user selection. A representative 
selection of computer generated video parameters at three fidelity levels is shown in 

Table T15-1 


Video Data Acquisition ansi Storage 

The video data may be acquired in High Definition TV (HDTV) or NTSC format 
and stored on analog tape or converted to digital and stored on mass storage^ The 
?toraae of v°deo data on analog tape is a mature technology and does not present 
special requirements However, due to the high bandwidth of digital video data, 

special techniques and technologies are required tor th e storage ol [ digital isthown fn 
The bandwidth and digital storage requirements for a NTSC video signa is shown 
Table T15-2 The significant use of digital video will require special processing 
hardware for data compressio n and a large 9 storage capacity, likely implemented on an 

optical disk. 


Video Subsystem Parameters 

The significant video subsystem parameters are shown at three different fidelity 
levels in Table T 1 5-3. 


TRW-SCS-89-T2 


An is 47 


Table T15-1 Computer Generated Video 
( Levels of Fidelity 


Parameter 


High 


Medium 


Low 


Image resolution 


1280X1024 


640X480 (VGA) 


Image 

representation 


Frame rate 


Solid modelling, 
multiple light 
sources 


3D wireframe 


30 frames/sec 


2 frames/sec 


Graphics source 


Video frame 
buffer, scanned 
image, CAD sys. 


Scanned image, 
CAD system 


640X350 (EGA) 


2D 


static 


CAD system 


Display control 


Pan, zoom, 


Pan, zoom, freeze 


SCS computer 
resource impact 


Significant HW 
and SW impact 


Medium HW and SW 
impact 


Pan, zoom 


Low HW and 
SW impact 
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Table T15-2 Digital Video Bandwidth and Storage Requirements 


1 1 

| Video Signal | 

1 1 

Bandwidth 

1 

| Storage 

J 

1 

1 

1 1 

| NTSC video signal | 

1 1 

6 MHz 

1 

| Analog video tape 

1 

1 

_1 

1 1 

| Uncompressed color ! 

j video, 512X680 res., j 

167 M bit/sec 

| 20.9 M byte/sec 

1 

1 

1 

| 30 frames/sec | 

1 1 


1 

J 

1 

1 

1 1 

| Simple compression | 
| techniques, 512X680 j 

6 M bit/sec 

1 

j 750 K byte/sec 

1 

1 

1 

1 

1 

j res., 30 frames/sec j 

1 1 


1 

J 

1 

1 1 

| DVI compressed color | 

1 .67 M bit/sec 

1 

j 209 K byte/sec 

1 

1 

j video, 100:1 


1 

1 

[compression, 512X680 j 


1 

1 

j res., 30 frames/sec 

J L 


1 

J 

1 

__L 
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Table T15-3 Video Subsystem 

Levels of Fidelit 


Parameter 

L 

High 

: 

Medium 



Low i 

Resolution 

2048X2048 

(digital) 

525 line NTSC 
(standard video) 

SSTV | 

(low rate) 1 

j 

1280X1024 

(digital) 

640X350 

320X200 ] 

l 

Screen size j 

25 inch 

| 19 inch 

13 inch | 


Video formal 


Range of color 


Remote camera 
control 


Remote VCR 
control 


Video switching 


SCS computer 
resource impact 


HDTV video 
(1125 line) 


65,536 colors 


Full 2-axis 
control, zoom 


Auto control for 
all functions 


Auto switching for 
up to 8 video 
sources 


No impact if fit. 
ECWS used, except 
for sim. video 


NTSC video (RS-170A) 
(525 line) 

EGA 


256 colors 

NTSC video (RS-170A) 


fixed camera 


manual, front 
panel control 


Manual switching 
for up to 4 video 
sources 


Significant HW/SW 
impact 


CGA 


16 colors 


no camera 


no VCR 


video from 
workstation 
display only 


low HW impact 
medium SW 
impact 
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Results 

The above analysis presented a wide range of fidelity options for the SCS video 
system. The level of fidelity selected will depend on SS video system fidelity, SCS 
training requirements, and funding considerations. Also, the requirements for training 
video will vary from payload to payload. The SCS will support the development of 
video for payload training from the resources at its disposal. The following candidate 
requirements are presented: 

1. The SCS video system will be compatible with the video subsystem of the SS 
Communications and Tracking system. 

2. The SCS video system will be capable of interfacing to the SSIS network. 

3. SCS video data will be be in a RS-170A (NTSC) format, and in color. 

4. The element, module, and attached payload trainers will support one video 
channel. 

5. The video system will support video data from the following: video camera, 
video recorder, external video source, and from a workstation based DVI source. 

6. The SCS will provide the capability to develop and display still and animated 
video images for training. The video images will contain sufficient detail to accomplish 
training. The computer based video will incorporate digital video interactive (DVI) 
technology. The DVI workstation will provide for the storage of the training video 
sequences. 

7. The video camera position will be controllable from a 3-axis hand controller and 
an external computer. 

8. The video system will have a video recorder which is controllable from an 
external computer and from front panel controls. 

9. The video system display will be a NTSC compatible color monitor with a 
screen size of at least 19 inches. 

10. The video system will be capable of switching any of the supported video 
sources to the display from a front panel control or from an external computer. 

11. The video system will distribute video data to the operator consoles, instructor 
stations, and to the POIC trainers. 

Open Issues/Notes 
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Study Title: Onboard Training 

Study No. T-20 Report Version 2 
Problem 

Onboard training may be required to make the Space Station Payload 
oDerations successful The long flight times may require refresher training for the 
onboard crew on payloads not operated in recent months. Also the crew onboard 
mav have a payload arrive with the next increment which they have not trained o 
Sue to the payloads late development), or which has changed to such a large extent, 
that the training they received before launch is no longer correct. 

Approach 

ExDerience with training on other systems will be reviewed, and, if possible, 
other training experts and/or flight crew will be contacted to discuss and resolve this 

issue. 

Analysis Overview 

Review and consideration of the SCS team's combined training experience 
was utilized to evaluate the various possibilities for onboard training This resulted in 

several candidate ways in which onboard training could be cond ^ cte 4 v ,^ b t o Space 
an Ed Gibson briefing in which he related the lessons learned on Skylab to Space 
Station We also had the good fortune to be able to discuss these in a JSC/MS 
coordination meeting with Claude Nicollier (Spacelab 1 flight crew) and Chuck Lewis. 
This discussion reinforced our basic conclusions. 


I nputs 

1 Briefing by Chuck Lewis to SS Training Working Group, February, 1989. 
2. Briefing by Ed Gibson, Skylab III astronaut, 7 March, 1989. 


Assumptions 

Analysis 

Our initial analysis, based on a considerable amount oft training and systems 
exDerience told us that onboard training could be done using 1) books, CBT, and 
audio/video onboard, 2) On-the-job training (OJT) with actual payload 

hardware/software, 3) an onboard simulation using some type ^ t h^C&Tst'Stem 

41 onboard traininq with the simulator on the ground, run through the C&T system. 
From this look at methods, we decided the best approach to selecting a method I was; to 
consider what problems could be solved using onboard training, i.e. what would be 
the principle purposes or uses of onboard training. 



TRW-SCS-89-T2 


From the systems view point, onboard training would be for emergency 
situations that are not faced often, but for which the correct response must be fast and 
correct the first time (e.g. onboard fire, rapid decompression, power failure). Onboard 
training would also be used for critical tasks which the crew gets rusty at if training was 
too far in the past, and the task itself has not been performed for a while 
(e.g. .reentering in the Apollo Command Module after it was docked to Skylab for 3 
months, or flying the Shuttle through reentry after it has been docked for weeks or 
months to the Space Station). This was gleaned from flight crew talks and discussions 

For payloads, both to refresh on a payload not run for a while, and to train for a 
payload launched in a significantly different configuration than that used in training are 
the valid reasons for onboard training. If a payload is present onboard, and the crew 
are reasonably familiar with it, if there is a training problem, it would most likely be 
resolved with on-the-job training (OJT) using the real payload, and not a simulation. 
More than likely, the PI would be on a communications link to the onboard crew to 
serve as the trainer and helper utilizing audio, and a video link if necessary. 

Given the above training purposes and use of OJT, it follows that onboard 
payload training would consist of using manuals, PC based simulations, or video and 
audio tape/disk training aids. All these would easily and efficiently serve to allow the 
onboard crew to refresh themselves on payload operations, or to prepare to operate a 
payload which had changed significantly since they trained on it. Also, a factor in not 
requiring a full up onboard payload simulation capability is that the 4 new arriving 
crew could readily aid in training the already onboard crew on a payload that had 
changed significantly, since the 4 new crew's training would be much more current 
than the 4 they were joining. 

Results 

A full up onboard payload simulator/simulation capability does not appear to be 
needed for payload training. Training for emergency situations caused by payload 
malfunctions would seem to fall within the systems emergency umbrella that is JSC's 
responsibility. 

Candidate Requirement 

The SCS manuals, PC based simulations, and video/audio tapes and disks 
shall be designed to be easily portable to and usable onboard the SSF for training 
purposes. 


Open Issues/Notes 
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Study Title : Techniques tor Supporting Late Changes to Simulators 

Study No. A-3 Report Version 2 

Problem 


How close to launch are changes allowed in the simulators, and what are the 
allowable magnitudes of the late changes. Small changes made too late in the cycle 
can have very adverse affects on not only the changed experiment, but other SCS 
support simulation activities. 

Approach 

The study will focus on state-of-the-art simulation development, emphasizing 
proven techniques and tools that could be incorporated into the SCS. To accomplish 
this study, reviews of current literature on state-of-the-art techniques and tools will be 
made and discussions with experienced simulator developers will be held to acquire a 
working knowledge of successful experience. 

Analysis Overview 

The two fundamental parts of simulators, hardware and software, are evaluated 
from the standpoint of state-of-the-art techniques and tools that can decrease the 
negative impact of late changes to SCS simulators. The techniques include modular 
programming and flexibility scenarios, and the tools include CASE and automatic 
programming. 

Inputs 

1. Case Tools For PCTC, Dave Scott, New Technology, Inc., Oct. 13, 1988. 

2. Reducing PCTC Software Development Time 

3. OP1 4 Plan Draft 1 D683-10135-1 
Assumptions 

10. Late changes to the simulators are a problem that the PTC/SCS people have to 
solve. 

Analysis 

To accomplish this study, reviews were made of current literature on state-of- 
the-art software engineering techniques that take full advantage of the constructs 
provided in the Ada programming language, and discussions with experienced 
simulator developers that have a working knowledge of successful hardware and 
software configurations. 
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The SCS simulations can be categorized into three basic classes : 

1. Flight equivalent hardware and flight software simulations 

2. Software simulation models 

3. Hybrid simulations: software and/or equivalent flight hardware / software 

Although all three classes will play some significant role in training exercises, it 
is estimated that (80 % to 90 %) of the payloads simulated are expected tp be done via 
software simulations. Therefore, a more significant portion of this study was given to 
class 2 than was given to either of the other two classes. However, to facilitate 
continuity within the study, the discussion begins with class 1. 

Flight Equivalent Hardware and Software 

One aspect that plays an important role in payload simulation is the use of 
hardware simulations. Since it will be impossible to use a full complement of actual 
flight hardware, flight equivalent hardware could be incorporated when available. By 
using flight equivalent hardware three basic situations develop affecting the 
composition of the simulations. These are (1) more flight equivalent hardware than 
flight software, (2) approximately an equal amount of flight hardware and flight 
software, and (3) a lessor amount of flight hardware than flight software. In all three 
situations the software aspect will be similar to the class 2 aspect. Therefore, any 
emphasis of software is postponed and will be incorporated in the discussion of class 
2. Thus, emphasis will be placed on hardware and hardware simulations. 

A change to a hardware simulator can have a definite impact on a training 
schedule depending on when the change occurred. If the change occurred on a 
particular simulator prior to training, then a change would have no real impact on the 
training schedule. However, if a change occurred on a particular simulator during 
training or after training completion, then definite problems would arise. One feasible 
approach that may be taken to offset the problem of a change during training is to 
modularize the hardware configuration to such a degree that maintenance and 
integration can proceed without impacting current operations. The trainer could shift 
emphasis to another aspect of payload simulation until the change is complete. In the 
situation where training is complete, the damage has already been done and 
retraining will have to be scheduled. However, the modular approach to hardware 
configuration could soften the training delay by having the simulator up and running 
with minimum impact or by allowing part of the simulator to continue to operate 
independently of the part that is changing. 

Software Simulation Models 

Spacelab experience indicates that 80 % to 90 % of payload simulations will 
be implemented using software. Whether this software is flight equivalent software or 
simulation models makes little difference to the discussion of late changes. 
Consideration must be paid as to how software can be developed to buffer the side 
affects of late changes. The most obvious place to consider software change 
techniques is in the original development process itself. Since Ada is the SSE 
programming language, any software development techniques used to develop 
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simulation software should be chosen to take full advantage of the Ada software 
engineering constructs. One such technique is object-oriented programming. It is 
documented that Ada and object-oriented programming are well suited for each other. 

Object-oriented programming is a modular design concept. The problem 
space is studied and decomposed into distinct objects. Each object contains both a 
description of the data types composing the object and all actions that can be taken on 
the object or by the object. By decomposing the problem into a series of distinct 
objects, the impact of late changes can be restricted to one module (object) or a 
group of modules (objects) and not scattered throughout the code. This capability 
would decrease the seek time ( the time required to locate the position within the code 
that needs modification or enhancement) and decrease the potential of the problem of 
not locating all code change positions. 

Another technique impacting software modification is growth and flexibility 
scenarios. This technique involves very close scrutiny of the system design and 
performing system design walk-throughs in order to determine major and minor impact 
points within the system design. If-then scenarios are investigated during the system 
design phase. Detailed documentation of the results of the scenarios can be used at 
a later time as a tool to evaluate the total impact of any late change to the overall 
system operation. 

CASE tools have come to the forefront in software development in the past few 
years and they have been used in a productive manner to develop software. 
Automatic programming (AP) is another software development tool that has received a 
lot of attention in recent years. AP is not currently to a state of development that it can 
be of great benefit in the generation of simulation software; however, if research 
continues at the current pace, it may hold real possibilities for software generation in 
the future. A combination CASE tool and AP that permits a user to make requirements 
modifications and then automatically generates those changes into baseline code 
would be beneficial by potentially providing a minimum impact to training. 

Hardware substitutions must also be considered for their impact to the software. 
These changes can be classified in two categories: 

1 . Software to hardware changes 

2. Hardware to software changes 

Software to hardware changes can be accomplished in a less traumatizing 
manner by using a software modularity approach. If the software has been designed 
using a modular technique, then any software simulated hardware configuration 
should be able to be replaced by the actual hardware or its equivalent with minimum 
impact. 

Hardware to software changes may not occur often, but if it should occur, then 
the modular approach to system design will be of assistance in this situation as well. 
Assuming that the simulator system design was modular, then any hardware 
configuration should be replaced with a newly developed software module or reusable 
software module with minimum impact up to the interface and protocol features. 
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Hybrid Simulations 

Hybrid simulations consist of a combination of flight equivalent payload 
hardware and/or software and software simulation models. The degree of the 
combination will vary from payload to payload, but this situation does not initiate any 
new problems. Since hybrid simulations are composed of both flight equivalent 
payload hardware and/or software and software simulation models, the previous 
discussions are valid in this situation as well. If both hardware and software designs 
adhere to strict modular design techniques, then any experiment training feature that 
can not be implemented in hardware can be simulated in a software model with 
minimum impact. 

It has been suggested above that late changes can be managed if significant 
forethought is provided early in the simulator design phase. But, once a late change 
has been determined, who decides the time needed to integrate and test the change 
and the immediate impact of such a change on the training schedule. One technique 
that has demonstrated promise in this area is a review board technique. A review 
board should consist of no less than one SCS system engineer, a PTC/SCS trainer, 
and the hardware and/or software designer. No change change would be 
implemented without the consent of this board. 

Throughout the discourse of this study, references have been made to minimum 
impact. To concluded this study, definitions are offered to clarify these references. 

Minimum Impact - A minimum impact results from any change to the simulator 
that has no detrimental effect on the training schedule, i.e. the training schedule can 
be maintained without delay. 

Minor Change - A minor change is any change that causes a minimum impact 
on the training schedule. 


Results 

1. The SCS simulators shall be designed using state-of-the-art modular hardware 
and software design techniques. Modular means dividing and subdividing the 
design into distinct working modules. 

2. The SCS shall be capable of incorporating a minor software change into an 

SCS simulator. The time required shall be determined by a review board. 

Incorporate includes requirements, design, code, test, integrate, maintenance, and 
documentation. Minor change is any change that does not cause a delay in the 
training schedule. 

3. The SCS shall be capable of incorporating a minor hardware change into an 

SCS simulator. The time required shall be determined by a review board. 

Incorporate includes interface and test. Minor change is any change that does not 
cause a delay in the training schedule. 
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4. No late change shall be incorporated into the SCS simulators without an 
evaluation of the impact to the training schedule. "Evaluation of the impact" includes 
an estimated down time and an estimated training delay time. 

5. The SCS shall incorporate state-of-the-art software development tools to be 
used whenever feasible in simulation software development. 


Open Issues/Notes 



TRW-SCS-89-T2 


Analysts 58 


Study Title: Requirements For Integrating Flight Equivalent Payloads 

Study No. A-5/A-14 Report Version 2 

Problem 

Enough must be known about the details of of what will be required of the SCS 
to support flight equivalent payload hardware and software to allow the proper 
requirements to be written. The types of Ground Support Equipment (GSE) services 
needed must also be determined to decide what impact these have on the SCS. 

Approach 

The study will determine the requirements of the SCS to support use of payload 
flight hardware and the requirements for GSE-Provided services. The approach for 
determining these requirements is to search through published reports, extract 
findings from various working groups, and hold discussions with users. 

Analysis Overview 

The current requirements baseline is that SCS is required to support the use of 
flight hardware, both payload and nonpayload. The implications of using flight 
hardware in the SCS is examined. Categories of GSE-Provided services are 
enumerated and analyzed. 

Inputs 

1. D683-1 01 35-1 OP1 4 Plan, Trainer Hardware/Software Development Control 
Plan 

2. SSP 30261 Architectural Control Document, Data Management System 

3. DMS Baseline, J. N. Dashiell, Nov. 29, 1988 
Assumptions 

Analysis 

This study investigates the potential impact on the SCS architecture of using 
flight equivalent hardware for representing core SS systems and payload 
experiments. The impact on the SCS is analyzed by examining how the actual 
hardware package would interface with the other functional components comprising 
the SCS, and whether these interfaces would affect computing resource requirements. 

The SCS is a simulation computer system concerned with the simulation of 
payloads for the Space Station. The simulations of SS core functions is the 
responsibility of the SSTF. The simulation of SS core functions which is required by 
the SCS in order to accomplish payload simulation will be performed by flight 
equivalent hardware or SSTF-developed simulators. A DMS kit is to be provided by 
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the JSC/WP02 contractor which will allow SCS access to standard SS software 
serves such as Operations Management Application (OMA) and the Network 
Operating System (NOS). The DMS kit will provide the hardware required to interface 
payloads 9 to the DMS and will include the Element < Control Work ®!?'°" 

MPAC(s) FDDI and other required networks, standard data processors (SD ), 
network interface units (NIUs), multiplexer-demultiplexer (MDM) mass storage unit 
(MSU), time generation system (TGS), and bus interface adaptor (BIA). 

The use of flight equivalent payload hardware and software offers full fidelity 
representation with a minimum requirement for simulation software to drive and 
process SS core and payload events dynamically Because some systems such as 
experiment payloads, may not be available within the time frame of f ^ S training a y 
solution should isolate the functional components of the SCS sc . hat real paygads 
and Davload simulation modules can be interchanged with a minimum impact. Other 
cons^erahonTsuch as a requirement for onboard Space Station training, may 
require that both flight equivalent payload hardware and a software simulation model 
be developed and implemented in the SCS. 

For this reason, the payload simulation, whether comprised of the flight 
equivalent hardware or a software model, should interface from aPPjcation to 
application through the payload network. By interfacing the payload s,r ™^tion in this 
manner, the details of the simulation are transparent to the rest of the system. 

A toD level SS DMS architecture is shown in Figure A-5.1. According to this 
figure, the payload instruments are attached to the payload I FDDI network in one of 
three ways; direct attachment to the payload network through a NIL) card set 
connection to a 1553 link to a SDP, which is connected to the payload network and 
connection to a MDM, connected to a SDP, which is connected to the payload 

network. 

The SCS will be required to support software simulation models and 
simulations which incorporate flight equivalent payload hardware ajd software. 
Payload simulations which are completely software based will not be mtedaced to a 
SDP or MDM These simulation models will be architecturally similar to case where 
the payload instruments are interfaced to the payload network through a network 
interface unit. If the actual payload is interfaced to a SDP or MDM, these functions will 
have to be simulated in software to obtain a high fidelity simulation. 

When flight equivalent payloads are used, the payload hardware must be 
stimulated by some means so that the experiment environment is simulated to the 
payload hardware. The specific method by which the environment is simulated will 
vary depending on the experiment. The SCS must be capable of providing a vanety of 
payload stimuli in the representation required by the payload ® x P er .'™®"t- 
payload stimuli will be controlled by the SCS. In this manner the SCS will con ol the 
experiment profile and be capable of introducing some anomalies into the experiment. 


Constraints - Proposed HW Configuration ibm 
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The SCS should require a minimum of SCS specific hardware resources such 
as dedicated networks, workstations, processors, etc. As a design goal, the SCS 
should control payload experiment simulation through the payload network from the 
user interface facilities of the ECWS or MPAC. The SCS executive may be able to 
utilize a dedicated standard data processor. Unless dedicated networks, workstations, 
and processors are used, the SCS will place an added load on the payload network 
and DMS resources beyond that required for SS operation. However, it is expected 
that that these resources will be able to handle the additional load, especially since 
the SCS will probably not be required to model all experiments simultaneously. 

In some cases the experiment may require resources such as fluids, gases, 
materials, etc. for proper experiment operation. Required facility services include 
electrical power, heating, cooling, gas and fluid transport system, and the building 
itself. Some US lab subsystems will also be required to interface to the SCS. These 
subsystems include: 

Vacuum Vent System 

Acceleration System 

General Lab Support Facility 

Preservation and Storage System 

Maintenance Workstation/Lab Sciences Workbench 

Mass Energy Analysis (MEA) Subsystem 

Process Materials Management Subsystem (PMMS) 

These special facility services will be GSE. It is expected that any experiment 
simulation at less than full fidelity will not require experiment-specific GSE services. 
Where GSE services are required, they may or may not be directly controlled from the 

SCS. 

Results 

The above analysis leads to the following candidate requirements: 

1. The DMS kit shall be provided by the JSC/WP02 contractor. The DMS kit shall 
allow access to standard SS software services. The DMS kit will provide the hardware 
required to interface payloads to the DMS and will include the ECWS, MPACs, 
networks, SDPs, NIUs, MDMs, MSU, TGS, and BIAS. 

2. The SCS shall be capable of providing payload simulations through software 
models, hardware models, flight equivalent payloads, and combinations of hardware 
and software. 

3. The SCS shall be capable of interfacing to the DMS applications and payloads 
through the application level services of the network operating system. 

4. The SCS shall be capable of generating signals and presenting them to the 
payload hardware, MDM, or the SDP in the representation required by them for 
experiment stimulation. 
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5 At the hardware level, the SCS shall interface to the DMS and SS core services 
through the standard interface buffer (SIB) provided by the DMS. 
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Study Title: Potential For SCS Expansion and Upgrade 

Study No. A-6/A-8 Report Version 2 

Problem 

This study looks at the development trends of major computing resources that 
will be required by SCS, and their effect on SCS and the SCS requirements.. The 
study is motivated by two SCS study issues: Issue A-8, Sizing Growth Potential in 
Capability/Capacity; and Issue A-6 Flexibility for Allowing Advanced Technology 
Insertion. 

Approach 

Current and projected technology is surveyed. The projections in this study are 
based on current technical literature and vendor briefings. 

Analysis Overview 

The formulation of a durable SCS architecture must take into account how 
forthcoming technology developments could promote changes to the initial SCS 
configuration. The objective of the present study is to survey the expected 
opportunities for enhancing SCS system hardware and software with emerging 
technology. It also considers the architectural consequences for SCS of being able to 
replace or expand original system hardware and software with new components. 

To focus on appropriate computing resources, the basic hardware and software 
requirements of a preliminary SCS system conceptualization were derived. The SCS 
requirement was segmented into five categories of computing resources which could 
be divided further into alternative types. The categories are: 1) CPU platforms, 2) 
mass storage subsystems, 3) video subsystems, 4) communications subsystems, and 
5) system interfaces. 

In the following sections, computing resources have been characterized on a 
few select performance variables. These estimates of current and future performance 
reflect what can be expected from the average top-end products of each type. 

Inputs 

Assumptions 
Analysis 
CPU Platforms 

Recent years have seen a broadening range of different computer types which 
today includes classifications such as mini-supercomputer, super- minicomputer, and 
super-microcomputer. These types join the traditional ranks of supercomputer, 
mainframe, minicomputer, and microcomputer. The SCS may have needs for a variety 
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of different computer types, and the range of alternatives for purposes of the present 
comparison will rely on the traditional four- category classification by subsuming their 
recent spin-offs. Thus, categories reflect the relative size of typical system 
configurations, although supercomputer refers to any computer using vectorization 
and parallel processing. 

The current and anticipated performance of computer platforms suitable for 
SCS application is charted for the next ten years or so in Table A6/A8-1 through Table 
A6/A8-4. Where available, data are used to express the approximate speed, capacity, 
and flexibility of CPU platforms projected in each category. While speed and capacity 
refer directly to data processing power, flexibility refers to system features such as 
compatibility with standards, modularity, and reconfigurability. Where possible, cost is 
related to units of performance. 

Overall, the tables indicate: 1) a convergence of platform capabilities, and 2) 
falling cost-to-performance ratios. The convergence appears to be predicated, in part, 
on an approach toward hard limits of microcircuit density and cycle speed for all CPU 
and RAM chips. On the other hand, the issue of flexibility in terms of being able to 
integrate different classes of computers in the same system, and possibly reconfigure 
the system down the road, seems to warrant primary consideration in formulating the 
SCS architecture. Indeed, emerging computer system architectures that emphasize 
cooperative distributed processing may depend heavily on this flexibility. 

A related trend in systems development is the accelerating move to 
customizable CPU's and logic devices with the advent of microcodable processors, 
ASICs, PALs, and rapid VLSI implementation. While this study does not directly 
examine specialized processors, except for vector or array processors that might be 
embedded in supercomputers, it is assumed that the implementation of these devices 
into computing platforms is crucial to realizing the projections contained in this study. 

In addition to both scalar and vector processing, graphics, data base, and 
logical inference processing are all moving toward more pipelined and parallel 
architectures. Along with the adoption of RISC techniques, parallelism is expected by 
1995 to have a significant impact on the processing power of computers and 
specialized co-processors that are available. The more distributed the SCS 
architecture, the more the SCS implementation should be able to capitalize on these 
kinds of developments. One specialized example expected within the next year is the 
Parallel Inference Machine (PIM) which is a proprietary "engine" capable of providing 
real time rule-based processing on the order of 100,000 logical inferences per second 
(lips). 

Speed. CPU Platforms 

Table A6/A8-1 presents typical instruction execution rates in terms of million 
instructions per second (MIPS) for different classes of computers and projects future 
trends. While MIPS have been used to characterize processing speed, this is only a 
very rough basis of comparison among different platforms. The nature of the platform's 
CPU architecture can significantly alter the relative weight of these generalized 
measures. The following factors, for example, will determine how these measures 
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translate into actual computing performance: processor type(s); instruction set; 

memory management; I/O control; memory size and access speed; code vectorization, 
branching, and optimization; multitasking; and multiprocessor topology. Some 
benchmarks (not provided) such as the Linpack set for vector processing and the 
Dhrystone set for scalar and system-oriented processing overcome some of these 
variables. 

Simulator systems such as SCS and real time systems in general often 
demonstrate a sensitivity to context switching. Context switch and interrupt service 
performance can be quite critical for real time, synchronized, and 
multitasking/multiprocessing operations. This sensitivity, if not adequately handled by 
the computer architecture, can prevent the system from achieving the speeds indicated 
in Table A6/A8-1. This problem certainly affects system performance. However, it is 
resolved with the use of a real time operating system and is not normally of concern at 
the application level. 


Table A6/A8-1 MIPS Trend 
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Capacity. CPU Platforms 

Table A6/A8-2 presents typical memory configurations for different classes of 
computers and projects future trends. 

Versatility. CPU Platforms 

As alluded to earlier, the operating system used with the CPU platform can be of 
paramount concern for real time systems. The compatibility among operating systems 
across different CPU’s within the system can also be of concern. While in the past, 
vendor computers have often been characterized by their proprietary operating 
system, the trend appears to be away from these exclusionary hardware/software 
configurations. The imminent switch to UNIX based operating systems by computer 
manufacturers such as IBM, DEC, and Cray is indicative of this trend. While UNIX is 
primarily intended for scientific applications, rapid prototyping, development, and 
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research, its hierarchical structure and support for the C language makes it amenable 
to specialized applications. The portability of the UNIX operating system also allows 
applications to be ported easily to different hardware platforms. An emerging 
standard, POSIX, is based on UNIX and promises to provide a common operating 
system across all the major hardware platforms in the near future. Table A6/A8-3 
projects the trend for Operating Systems Standards across various classes of 
computers. 


Table A6/A8-2 RAM (MB) Trend 
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Table A6/A8-3 Operating Systems Standards Trend 
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Cost. CPU Platforms 

It is expected that the cost/performance ratio for computing wilt continue to 
decline, perhaps even more dramatically than in the past. A cost/performance 
projection for various types of processors is presented in Table A6/A8-4. 


Table A6/A8-4 Cost $1 000/MIPS Trend 
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Mass Storage Subsystems 

Disk and other mass storage strategies are undergoing significant revision in 
the wake of new optical storage developments. Storage devices using optical and 
hybrid opto-magnetic and vertical recording techniques are providing very large 
capacities at reduced cost, especially for archival applications. Table A6/A8-5 through 
Table A6/A8-8 demonstrate that other performance aspects of optical storage are 
converging on more conventional magnetic media. 

While the present disadvantage of WORM optical disk systems is the slow 
average read/write access time (where separate erase and write cycles can consume 
a total of 200 - 500 msec), the media cost (of $.20 per MByte) is significantly lower than 
magnetic tape and falling. Archival storage for SCS, including telemetry data 
samples, scenarios, and recordings of simulator training sessions, may present a 
substantial requirement. Within the next year or two, rewritable optical drive (ROD) 
products will offer rapid (30 msec) data storage/retrieval with GByte capacities to 
support high speed data representations within SCS. Optical disk technology is in its 
infancy and has performance deficiencies when contrasted with magnetic disk 
technology at this time. However, as optical disk technology matures, performance will 
increase to the level of magnetic disk technology, and may ultimately surpass it. 

Mass storage strategies are appropriate to specific patterns of data utilization. 
Appropriate strategies will distribute these functions across the system hierarchy of 
linear buffering, addressable cache, extended store cache, memory, fast (magnetic) 
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disk disk mirroring, slow (optical) disk, tape or other sequential storage, and optical or 
other archival media. Disk arrays may also be formed to improve reliability and 
combined access and transfer times. The SCS architecture, in order to preserve 
flexibility, would need to provide some redundancy of storage modes across real time 
and transactional levels of the system. 

Speed. Mass Storage 

A projection for the access time of magnetic and optical mass storage devices is 
presented in Table A6/A8-5. Another important performance parameter, Disk I/O 
Transfer Speed is projected in Table A6/A8-6 in terms of MBytes/sec. 


Table A6/A8-5 Mass Storage Access Time (ms) Trend 
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Table A6/A8-6 Disk I/O Transfer Speed (MBPS) Trend 
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Capacity. Mass Storage 

The mass storage capacity available on a single drive in terms of gigabytes 
(GB) is projected in Table A6/A8-7 for magnetic and optical disk technology. A 
qiqabyte is equivalent to 1000 megabytes. Controller speed and capacity for number 
of devices does not vary greatly from one class of computer to another and is not 
shown. The compatibility of controllers across different media devices, however could 
prove to be very important in the long run for the SCS architecture. Table A6/A8-8 
contrasts this capability. 
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Table 

A6/A8-7 Mass 

Storage (GB) Capacity Trend 
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Versatility. Mass Storage 

The interface between the CPU and the disk drive is an important component of 
system performance. Generally, proprietary controllers are used today. The use of 
standard interfaces between CPU and disk increased modularity and is encouraged. 
Table A6/A8-8 projects trends for Standard Disk Interfaces. 


Table A6/A8-8 Disk Interface Standards Trend 
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Cost. Mass Storage 


The cost of mass storage is projected in Table A6/A8-9. 
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Table 

A6/A8-9 Mass 

Storage 

Cost ($/MB) Trend 
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Video Subsystems 

The salient alternative in video capabilities for SCS is the use of analog versus 
digital systems. Trends in both domains fail toy suggest that commercial 
implementation of any major advances in video display technology will occur in the 
next ten years. 

It is assumed that onboard SS video distribution is in an analog format. Where 
practical, SCS video from modulated signal sources including cameras, tape 
machines, and video disk players will easily approximate SS video systems and may 
use flight equivalent hardware. In these cases, hardware considerations will be driven 
by actual SS standards and requirements. In other cases where the approximation is 
only functional, current systems such as Super VHS should suffice. The development 
of HDTV should not alter the SCS configuration in this regard unless SS requirements 
are upgraded. Where detailed, rendered imagery is necessary for dynamic scenes 
such as EVA, animation from computer generated imagery may be necessary. 

Realism in computer generated imagery comes at considerable cost in 
horsepower to accomplish the necessary coordinate transforms, hidden surface 
removal, surface shading, antialiasing, and other forms of rendering. In recent years 
workstations designed to support solids modeling have led the thrust in graphics 
technology. By 1 990, however, the very fast raster drawing and shading capabilities of 
these specialized computers will be available at the single board level. This advance 
will permit an inexpensive box to offer high resolution real time animation, provided 
that the dynamics of the scene can also be calculated rapidly enough. Boxes utilizing 
new video chip sets from makers like Texas Instruments (340/440XX series), for 
example, could soon achieve rates of 100,000 Gouraud shaded polygons per second 
and still have 20 MIPS left over for scalar processing. This performance is projected to 
be available at a tenth the price of current workstations. 

Display of video from stored sources such as digital video interactive (DVI) may 
also offer substantial performance. This performance is gained from the potentially 
rapid access under intelligent control of a large number of detailed image frames. The 
frames are formulated and written once. If visual scenes are predictable along some 
constraints, then frame sequences can usually be permutated at will. Capacities of 
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DVI disks are anticipated to rise substantially after 1995. Improved recording densities 
and compression techniques will account for the rise. 

Chaotic compression (fractals) can achieve very high compression ratios on 
some scenes, but decoding is presently not executed in real time (best is four frames 
per second). The leading example of these systems, the Iterated Function System 
Image Synthesizer (IFSIS), is expected to be commercialized in the 1990 to 1992 time 
frame. Such products could reduce the data bit load by a factor of 1,000 to 10,000 
depending on scene characteristics. 

Standardization in this realm may prove to be a continuing problem unless 
compression is tied directly to the video mode and broadcast or media standard. This 
kind of standardization for computer generated imagery is less likely. Several recent 
attempts to forge standards (e.g., CORE and NAPLPS) have not achieved compliance, 
although powerful capabilities like object rendering may achieve de facto 
standardization through emerging graphics languages. 

Speed. Video System 

A projection of video frame drawing speed is presented in Table A6/A8-10. 


Table A6/A8-10 Frame Drawing Speed (Kpolys*) Trend 
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Capacity. Video System 

A projection of video resolution in terms of pixels per screen is presented in 
Table A6/A8-1 1. The compression ratio trend is projected in Table A6/A8-12. 
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Table A6/A8-11 Video Resolution Trend 
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Versatility. Video System 

A projection of video format standards is presented in Table A6/A8-13. 
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Table A6/A8-13 Video Format Standards Trend 
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Communications Subsystems 

Network systems are presently evolving along several different lines of 
development. At the same time, networks are proving to be a critical factor in the 
architecture and design of modern real time and distributed cooperating systems. 
Consequently, the communication strategies, network topologies, access 
mechanisms, and hardware/software systems available for SCS design choices will 
probably determine much of its ultimate success. The following tables consider four 
general categories of networks: broadband; and baseband in three topologies: token 
ring, star, and bus link. (The categories tend to reflect vendor offerings more than 
technical distinctions because one could have, for example, a broadband star 
network.) 

While Table A6/A8-1 4 through Table A6/A8-17 reflect a dramatic increase in the 
throughput of upcoming network systems, it is important to consider two facts. First, 
except for high fidelity representation of video data, the data flows of the SCS are not 
expected to demand such capacity or speed. Second, the SCS will make use of and 
be compatible with the SS Data Management System (DMS) architecture. 
Consequently, the SCS will support the DMS network operating system (NOS). 


Speed. Network 

The network bandwidth for various network topologies is presented in Table 
A6/A8-14. 

Capacity. Network 

The number of stations supported by the network is projected for various 
network topologies in Table A6/A8-15. 
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Table A6/A8-14 Network Bandwidth (Mbps) Trend 
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Versatility. Network 

Access mechanism standards for networks are projected in Table A6/A8-16. 
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Table A6/A8-16 Access Mechanism Standards Trend 
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Cost. Network 







Network costs in terms of dollars/Mbps/node are projected in Table A6/A8-17. 


Table A6/A8-17 Cost ($/Mbps/Node) 
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System Interlaces 


Interface requirements within the SCS include two primary types of hardware: 
(1) user interface devices including displays and controls for the simulated lab 
environment and the simulator control stations; and (2) equipment interface devices 
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such as digital-to-analog converters, multiplexers, actuators, et cetera. Requirements 
also include software and programming interfaces. 

Hardware 

One aspect of SCS processing that could have a substantial impact on 
computing resource requirements is the conversion and compression of signals from 
high rate data sources. Both CPU generation and network communications 
requirements, as well as mass storage speed and capacity, for these data streams will 
be inversely proportional to the data compression and data filtering ratios achieved. 
Progress in hardware and software techniques for real time conversion is accelerating. 
Presently, proven techniques exist to compress audio data to 8 Kbps and NTSC video 
to 45 Mbps. At these rates, digitization and compression are expensive. 

Software 

The software development environment for the SCS will be based on the SS 
Software Support Environment (SSE). This environment will provide a rich variety of 
development and analysis tools for system development. The appropriate selection 
and utilization of tools from that environment for SCS development is crucial to the 
overall success for SCS. Software paradigms and programming environments, like 
operating systems, will be very important to SCS's overall flexibility and its ability to 
interface readily with SS derived elements and potentially unique simulator 
subsystems like a payload stimulator or a highly automated scenario generator. 
Foremost in the SCS programming environment will be the capability of rapidly and 
accurately building payload simulation models which will interface in a modular 
fashion with the rest of SCS. These simulation models should be easy for both staff 
and principal investigators to construct. Object oriented design and programming 
systems that are expected to characterize the next generation of Integrated CASE 
tools offer an attractive platform for these efforts. Commercial object oriented data 
bases are being introduced which suggest that in a few years they could be effective 
vehicles for both model development and the actual real time implementation of SCS 
simulation. Object oriented systems also offer the distinct advantage (for meeting 
simulator production and evolution demands) of intelligently managed libraries of 
generically reusable code modules. 

Other system software concerns include the emerging models for user interface 
standards. IBM's Systems Application Architecture (SAA) is an example of the kind of 
look-and-feel standardization which is expected to be prevalent by 1995. Combined 
with device independent terminal formats (such as X- Windows 11), general graphics 
languages, and common operating systems, the integration of different computer 
platforms into the SCS can be planned for within the initial architecture. 

SCS Architecture Requirements 

The impact of technology developments on the SCS and architecture will be felt 
in those areas where the demands on computer resources are the greatest. Once 
training and operations requirements are compiled, SCS functional capabilities that 



TRW-SCS-89-T2 


Analysis 77 


appear costly or difficult to implement using computing resources based on current 
technology can be identified. System level capabilities to be considered will include. 

1) Automated simulator control and operation. 

2) Real time dynamic simulation. 

3) High fidelity representation of simulated entities and events. 

4) Synchronized system-wide response to high rate and volume of simulation 
events. 

5) System capacity and integration to simultaneously conduct multiple 
simulation scenarios. 

The incorporation of new or advanced types of computing resources that could 
improve the implementation of selected SCS capabilities can occur in two respects. 
First, the availability of new products for SCS can be anticipated and included in the 
preliminary designs. Second, design decisions can be made, such as the 
implementation of a modular architecture, to maximize the system’s ability to accept 
new components. The relative difficulty of uncoupling the original computing resource 
types and coupling in new types needs to be assessed for each function and 
subsystem implementation. In the final architecture formulation, these SCS expansion 
and replacement costs can be related to the performance gains expected from using 
each candidate computer resource advancement. 

Results 

Based on the above analysis of future trends for computing technology, the 
following candidate requirements are presented: 

1. SCS system components will be designed in a modular fashion so as to allow 
upgrades and enhancements to the SCS to be made easily. 

2. SCS software components will be developed with SSE. 

3. SCS system components will be compatible with DMS network operating 
system (NOS). 

4. The SCS will implement standards used by the Space Station, where possible. 
Where no SS standard is available, industry standard protocols, systems, and 
interfaces will be used. 

5. The SCS operating system used by the host processors will be portable, have 
real time features, and be based on an industry standard. 

6. The SCS will be designed to anticipate advanced technology insertion. 


Open Issues/Notes 
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Study Title: Implications of Simulation Development Cycle 

Study No. A-7; Report Version 2 

Problem 

To define the simulator development load on the SCS, we must expand on the 
analysis done as part of the effort captured in the SCS Study Issues Report. 
Assessment of the development load is key to sizing the SCS system. The 
development load and training load will constitute nearly all, if not all, of the loading on 
the SCS system. The third function, Operations Evaluation, is expected to be largely 
performed as part of training, and will thus contribute only a very small additional load 
to the SCS system. 

Approach 

Analysis of the training flow has been completed and baselined as part of study 
T-1. Based on the training flow, and code size estimates, the development flow and 
size will be derived. Other approaches will be evaluated, and if applicable will be 
utilized as a second method of arriving at the SCS development load. 

Analysis Overview 

The training flow as summarized in study T-1 was utilized as were the code 
sizes from T-1. Assumptions from the SIR report were used to calculate the code 
under development at any point in time. The last paragraph discusses a second size 
estimate based on past Spacelab experience. 

Inputs 

1. Study T-1 PTC Training increment Flow Requirements. 

2. SCS Study Issues Report, 19 December, 1988 
Assumptions 

1 1 Payload change out per increment will be a worst case of 1 5% per increment. 

12. Payload simulations are software simulations 90% of the time. 

13. Development will be done concurrently with training on the day shift. Swing 
and midnight shifts will be reserved for PM, CM, and backups. 

Analysis 

The PTC Training Increment Flow Requirements (Figure T-1 .1 in Study T-1) 
shows four crews and the POIC cadre training at the PTC simultaneously. This figure 
is the base for the training flow and load in the SCS. The development load is 
overlaid on this to produce the PTC Training Increment Flow Requirements, with 
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Simulator Development Overlay (Figure A-7.1). The development overlay is derived 
from the Single Medium Complexity Experiment Development Cycle (Figure A-7.2) on 
the next page. It is estimated, based on the SCS team's combined software 
development experience, that this medium cycle represents a good average. 
Complex simulations will no doubt take 3 to 4 months longer, and simple experiments 
may take 3-4 months less time to develop. But overall, an 11 or 12 month simulator 
development cycle seems correct. 

Graphic analysis using the Development overlay chart shows that, using this 12 
month average, that all four development phases will be in progress (for different 
increments) at any one time. Our assumption of a maximum of 15% change out per 
increment, and our 90% software simulations means that ongoing development will be 
the size of 54% of a single US Lab/attached payload increment. Utilizing the software 
sizes for payloads from T-1 yields a total US Lab/attached payload simulator 
development code size of: 

Line of Code 

7 complex models = 242,900 
10 medium models = 220,000 
26 simple models = 185,900 


US Lab + AP Total 648,800 

This number of lines is then then multiplied by 54% to yield the number of lines 
of code under development at any given time on the SCS: 

350,352 Lines of code under development 

Using 150 lines of code per MM, and 12 MM per MY, yields 1800 lines of code 
that can be developed in one man year. Given that this cycle is one year long, this 
yields: 


350,352 LOC / 1800 LOC per developer = 195 developers 

This means that 195 developers would be needed at all times, and all these 
developers would be using the SCS for preliminary design (CASE tools, word 
processors, chart making tools), detailed design (PDL tools, CASE tools, chart making 
tools), code (editors, generators, and compilers) and unit test (editors, generators, 
compilers, test building tools, debuggers, unit test runs), and acceptance testing(l&T 
tools, l&T runs, V&V tools, V&V runs, CM tools). 
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FIGURE A-7.1 PTC TRAINING INCREMENT FLOW REQUIREMENTS 
with SIMULATOR DEVELOPMENT OVERLAY 
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Spacelab historical perspective and plans are a different way of looking at this 
problem. Spacelab has about 30 simulator developers, and this team has sustained 
an actual flight rate of approximately one flight per year of 8 to 12 payloads per flight. 
Given 43 payload to be simulated for one SS US Lab increment, a change out 
maximum of 15% assumed per increment, and a flight rate 4 times that of Spacelab 
means that the PTC must develop approximately 3.5 times the number of simulators 
produced by Spacelab in one year. This yields: 

30 X 3.5 = 105 developers 

Results 

This analysis shows that the SCS development host and/or SPF must be able 
to support between 105, and 195 software developers running concurrently with 
training. 

Candidate Requirements 

1. The SCS system shall be able to support development of all the software (90% 
of the total number of PTC simulators) simulations needed to support the required PTC 
training flow. 

2. The SCS shall have the required computer speed and capacity to support this 
development during the same hours as the training function is performed, with no 
significant (less than 10%) degradation from the stand alone speed or performance of 
the development tools. 

Open Issues/Notes 
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Study Title: Fidelity of DMS Interface 

Study No. A-10; Report Version: 1 

Problem 


This study will examine the required fidelity of the DMS interface for the SCS. 
At issue is whether a DMS kit is required for high fidelity payload simulation and 
training, or whether a DMS simulator could provide sufficient fidelity for payload 
training. 

Approach 

The DMS requirements will be analyzed through study of the architecture 
control documents, presentations, and discussions with the developers and the 
training community. 

Analysis Overview 

The DMS requirements are presented in a summary fashion. The structure of a 
payload experiment or model is analyzed to determine the required DMS services 
from the viewpoint of the experiment or model. In addition, the DMS interface 
requirements to SS core services are discussed. 

Inputs 

1. SSP 30261, Rev B Architectural Control Document, Data Management System 

2. DMS Baseline, J. N. Dashiell, Nov. 29, 1988 

3. Data Management System Concepts, J. T. Spainhour, Boeing, Mar. 17, 1988 

4. Simulator/Trainer/Mock-up Classification, Dennis Dahms, Mission Operations 
Directorate, Nov. 15, 1988 

Assumptions 

14. The PTC will not be responsible for any subsystems training. The PTC will 
utilize the minimum subsystem interfaces required to support payload training. 

15. The PTC will use NASA-provided DMS kits. 

16. A host-based DMS functional simulation (FSIM) to be provided by SSE will not 
run in real time. Thus, FSIM is assumed to be of minimal utility in the SCS. 
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Analysis 

The Data Management System (DMS) provides the computational, storage, 
data acquisition, user interface, and network resources for the Space Station. All 
electrical systems, including payloads, interface to the DMS. In addition to hardware 
resources, the DMS includes standard software services for SS systems, and 
operations management services through the Operations Management System (OMS) 
and the Operations Management Application (OMA). A summary of the DMS 
components is given below. 

DMS Components 

Hardware 

Standard Data Processor (SDP) 

Mass Storage Unit (MSU) 

Multiplexer/Demultiplexer (MDM) 

Embedded Data Processor (EDP) 

Network Interface Unit (NIU) 

Bus Interface Adapter (BIA) 

Bridge 

Gateway 

Multipurpose Application Console (MPAC) 

Time Generation System (TGS) 

Networks 

Software 

Standard services used by applications 
Operating System 
Network Operating System 
User Interface Management System (UIMS) 

Data Storage and Retrieval (DSAR) 
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Integration, Test, and Verification (IT&V) 

Fault Tolerance and Redundancy Management 

Data Acquisition and Distribution Services 

MPAC Workstation Services 

User Interface Language (UIL) 

Management services for the DMS and the Space Station 

Operations Management System (OMS) 

Short-term planning 
Coordination of the short-term plan 
System and payload status monitoring 
Management of inter-system and payload testing 
Logging of global configuration and activities 
Management of global base Caution and Warning 
Global base fault management and reconfiguration 
Support of command and uplink/downlink management 
Global base inventory management 
Support of onboard simulations and training 

Pavload Applications 

All onboard applications, including payload applications, utilize the DMS 
system components and services. Flight equivalent payload applications reside in 
one of three places; a SDP, a EDP within a MDM, or another processor interfaced to a 
MDM. To communicate with the experiment or the operator through the MPAC, the 
payload application makes use of the DMS standard services. Communication with 
DMS standard services generally consists of calling or being interrupted by the service 
desired and passing parameters. 

A part of the payload application, the user interface, must also reside on, or be 
accessible to, the MPAC. Through the user interface, the operator controls the 
experiment. This is accomplished by exchanging messages between the MPAC and 
the payload application. The experiment can also be controlled through the 
experiment control and display panel. 

Software models can also be used to simulate the payload application. The 
software model uses the DMS services, like the flight equivalent experiment, to 
provide a high fidelity representation of the payload. A software model can also be 
used to stimulate the payload model through the MDM to simulate the SS 
environment. This software model of the payload can be executed from a variety of 
platforms including a SDP, a EDP within a MDM, another processor interfaced to a 
MDM, or a simulation host computer. 
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To maintain the required high level of fidelity, it is preferable to utilize the flight 
articles for training. However, it is anticipated that the flight articles may not be 
available for training on the first few launches. The development of software payload 
models of experiments is a significant undertaking, in terms of cost and time. If 
software models are to be developed for training, it is critical that the software models 
developed for the experiment be used throughout the training cycle. In other words, 
the same software model should be transportable between the Part Task Trainers, the 
Element and Module Trainers at the PTC, and the payload trainers at the SSTF. 

The transportability of software models between the various training facilities 
has implications on the fidelity of the DMS. While not all DMS services are required 
for flight equivalent payloads, payload models, and all training environments, those 
DMS services and applications which are used must be of sufficient fidelity to allow 
transportability of payload models. If these requirements are met however, a software 
simulation of the DMS, instead of the DMS kit, could be used for training. However, to 
insure transportability between facilities, DMS Kit hardware and software must be 
utilized. 

In the Part Task Trainer, interactions between the SS core systems and other 
payloads are of lesser importance. Rather, the Part Task Trainer provides the operator 
early training about payload-specific operations. Thus, for some of the PTTs, a high 
fidelity software simulation would suffice. In the later phases of training, when the 
payload training has been moved to the Combined and Consolidated trainers, 
interactions between the experiment, other payloads, and the SS core systems 
become more important. Thus for the Combined and Consolidated trainers, DMS Kits 
should be utilized. 

The required fidelity of a DMS simulation is therefore dependent on the training 
environment in which it is to be used. A DMS simulation within a Part Task Trainer 
would be required to model at a high fidelity only those DMS services required for 
early payload training. Other DMS services could be modeled at a low fidelity level or 
omitted entirely. 

Results 

The above analysis lead to the following candidate requirements: 

1. Flight equivalent payloads and software payload models will be transportable 
between the Part Task Trainers, the Element and Module Trainers at the PTC. 

2. The Part Task Trainers will be used for early training, and payload-specific 
training. 

3. A simulation of the DMS may be utilized in the PTTs, provided that payload 
models developed with it can also be used with a DMS kit, and that sufficient fidelity to 
provide good payload training is provided. 
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Study Title : The Definition of No Single Point of Failure 

Study No. A-11 ; Report Version 2 

Problem 

This issue involves the level of need for backup for every SCS component, and 
the consequent cost of not having a backup for every component, i.e. no single point of 
failure. 

Approach 

The approach to researching this study was to examine the availability and 
reliability requirements of simulators with a purpose similar to the SCS simulators. 

Analysis Overview 

The analysis for this study provides a definitions of reliability, availability, and 
maintainability (RAM), and presents the RAM requirements for no single point of 
failure. 

Inputs 

1. Requirements specification document for the Computing Development System 
(CODES), a TRW study performed for the U. S. Army Strategic Defense Command. 

2. Requirements document for SSTF software development facility for Spacelab 
payload simulation. 

Assumptions 

Analysis 

This study investigates the interpretations of reliability, availability, and 
maintainability. The information was acquired by examining the SSTF requirements 
document, utilizing the TRW produced Computing Development System (CODES) 
requirements specification document, and personal interviews with TRW personnel 
who are currently using the Software Development Facility Extension (SDFE) for 
Spacelab payload simulator development. 

No single point of failure is an extremely important issue from the training 
viewpoint. It is important that the PTC be able to conduct its training programs without 
significant impact due to system hardware failures. In most cases, the schedules of 
the personnel involved in training will be booked solid far in advance, which will make 
it expensive to reschedule a training session that has to be canceled due to a facility 
problem. Training exercises that involve experiment team representatives with the 
crew and ground operations cadre may involve travel for a large number of the 
participants that cannot be rescheduled without significant costs to the program. 
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Thus, the basic issue here is the cost of backup hardware vs. the cost of lost training 
time for a system which has many single points of failures. 

Discussions and analysis have pointed toward an alternative to specifying no 
sinqle point of failure. This is specifying the SCS in terms of "ilities" to minimize the 
cost and impact on training of system failures. Other training systems have used this 
approach It is an appropriate requirements solution, since the performance of both 
hardware and software are bound by three "ilities": reliability, availability, and 

maintainability. The applicable definitions for all three follow. 

Reliability - System reliability is the extent to which the system will perform a 
required function under stated conditions for a stated period of time. Reliability can 
be determined by the following formula. 


Reliability = (No. of successful applications)/(No. of attempted 
applications) 


Availability - System availability is the portion of total operational time that the 
system performs or supports simulations. Availability can be calculated using the 
following formula. 


Availability = (MTBF)/(MTBF + MTTR) 

where MTBF is mean time between failure and 
MTTR is mean time to repair. 


Maintainability - System maintainability is the effort required to locate and 
correct a fault in the system. Since the payloads will be software intensive, the 
software design and the completeness of the operating manuals will greatly affect 
the maintainability of the system. 

The minimum requirements for the SCS simulators with respect to reliability and 
availability will correspond to the values contained in the table below. The values in 
table are representative of the time when the system is required to be active and not 
real clock time. The values were determined by researching simulators and 
documents with similar purposes. The simulators include the SDFE and SSTF and 
the documents included the TRW CODES study. 


Reliability 
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MTBF Availability MTTR (HW1 MEEEUSW) 
98% 270 hrs 97% 8 hrs 8hrs 


The MTBF values specified will be achieved during acceptance testing. The 
MTBF measure will be the estimated cumulative MTBF for the hardware and each 
software function during the last third of the acceptance test. 

In order to satisfy the requirement for reliability, availability, and maintainability, 
it will be necessary for the SCS to exhibit certain design characteristics and attributes. 
These design characteristics and attributes are identified below. 

- The design should be such the any single component failure does not 
affect the ongoing operations of all other components. 

- The design should allow maintenance to be performed on a failed 
component during normal operating hours and it should allow a repaired 
component to be reinstalled to operational status without impacting the 
remaining operations. 

- All scheduled preventative maintenance should not interfere with normal 
working operations and preventative maintenance should be a minimum of 
32 hours/month and a maximum of 40 hours/month. 


Results 

1. Reliability for the SCS simulators shall be 98 %. 

2. Availability for the SCS simulators shall be 97 % with MTBF (270 hrs) and 
MTTR (8 hrs for either hardware or software or 1 training day) 

3. The SCS simulators shall exhibit the following characteristics: 

- The design shall be such the any single component failure does not affect 
the ongoing operations of all other components. 

- The design shall allow maintenance to be performed on a failed 
component during normal operating hours and it shall allow a repaired 
component to be reinstalled to operational status without impacting the 
remaining operations. 

- All scheduled preventative maintenance shall not interfere with normal 
working operations and preventative maintenance should be a minimum of 
32 hours/month and a maximum of 40 hours/month. 


Open Issues/Notes 
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SCS Study Analysis Assumptions 

1 worst case load on the SCS is assumed for payload models which might be 
simulated by either physical hardware or a simulator executing on the PTC SCS. 

2 Code size estimates are based on Spacelab experience using structured 
analysis and FORTRAN coding. These estimates may be reduced using new CASE 
tools and new programming methodologies. 

3. OMS functionality with respect to the onboard application (OMA) will be 
provided by the flight software resident on the DMS kits. OMS functionality with 
respect to the ground application (OMGA) will not be a part of the DMS and will 
have to be provided by other means. 

4. A worst case load on the SCS is assumed for subsystem models which might 
be required to support payload training. 

5 The SCS ECWS is not required to provide the nonpayload related functionality 
of the flight equivalent ECWS. However, the flight equivalent ECWS may be used for 
the SCS ECWS. 

6. The SCS video system will be compatible with the video subsystem of the SS 
Communications and Tracking system. 

7. The SCS video system will be capable of interfacing to the SSIS network. 

8. The SCS video system, while compatible with the SS video subsystem, is not 
required to provide 100% of the functionality of the SS video subsystem. 

9. SCS video data is not required to be digitized and sent through the C&T system 
to the POIC. 

10. Late changes to the simulators are a problem that the PTC/SCS people have to 
solve. 

1 1 . Payload change out per increment will be a worst case of 15% per increment. 

12. Payload simulations are software simulations 90% of the time. 

13. Development will be done concurrently with training on the day shift. Swing 
and midnight shifts will be reserved for PM, CM, and backups. 

14. The PTC will not be responsible for any subsystems training. The PTC will 
utilize the minimum subsystem interfaces required to support payload training. 

15. The PTC will use NASA-provided DMS kits. 
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16. A host-based DMS functional simulation (FSIM) to be provided by SSE will not 
run in real time. Thus, FSIM is assumed to be of minimal utility in the SCS. 
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